From patchwork Mon Sep 27 15:33:59 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adolf Belka X-Patchwork-Id: 4747 Return-Path: Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4HJ6B76W5Pz3x1J for ; Mon, 27 Sep 2021 15:34:07 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4HJ6B74Xfwz13M; Mon, 27 Sep 2021 15:34:07 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4HJ6B73Pwfz2yNY; Mon, 27 Sep 2021 15:34:07 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4HJ6B64bMpz2x9g for ; Mon, 27 Sep 2021 15:34:06 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4HJ6B60J6lzNh; Mon, 27 Sep 2021 15:34:06 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1632756846; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=/LEGEz9hpXwoJDhDM5mBT+D6rWi7W684ugHyVFOHMX4=; b=/QzTZVRXvu+Dmc9qit+Q9A8LJuL4O73VOvpCNAK309IV6YTTNG0LB+So7FjrTpYJacI6g9 Xk/zCMUsCyBWmzCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1632756846; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=/LEGEz9hpXwoJDhDM5mBT+D6rWi7W684ugHyVFOHMX4=; b=d4e0EnOWsvGFNfi/dO/U5R35XA/sBRbshwr+5bYAe0pz9HwRAl+dhqIZYBYVrC/X9N5vKU uqlMC7G1mfNhFjumC8LcqkCgfEvZvB57HCG4DjPeX6z8C1LTppsXfSTnG3QP4eU54s9wrY IAPAydvgQ2w2xDgXuyRfyYTzmROMx4xBfA4Co9HrWhS4CN4OWybfw0Qk+ahIE7ps80vm4a aeGHcnbpNZFO41y9hduyLN0Q3D5Sf34MTXIN96Bxmozp8Ef97MVwE3fzZnUYZaE2Ho4w+5 3zY2BGyixirsxyT0eCdpfMYKcd2InngiRPUHOUv54xQPJjleH1GBLQ/dBz0oZQ== From: Adolf Belka To: development@lists.ipfire.org Subject: [PATCH] openssh: Update to version 8.8p1 Date: Mon, 27 Sep 2021 17:33:59 +0200 Message-Id: <20210927153359.1500601-1-adolf.belka@ipfire.org> MIME-Version: 1.0 X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: development-bounces@lists.ipfire.org Sender: "Development" - Update from 8.7p1 to 8.8p1 - Update of rootfile not required - Changelog OpenSSH 8.8p1 Future deprecation notice A near-future release of OpenSSH will switch scp(1) from using the legacy scp/rcp protocol to using SFTP by default. Legacy scp/rcp performs wildcard expansion of remote filenames (e.g. "scp host:* .") through the remote shell. This has the side effect of requiring double quoting of shell meta-characters in file names included on scp(1) command-lines, otherwise they could be interpreted as shell commands on the remote side. This creates one area of potential incompatibility: scp(1) when using the SFTP protocol no longer requires this finicky and brittle quoting, and attempts to use it may cause transfers to fail. We consider the removal of the need for double-quoting shell characters in file names to be a benefit and do not intend to introduce bug- compatibility for legacy scp/rcp in scp(1) when using the SFTP protocol. Another area of potential incompatibility relates to the use of remote paths relative to other user's home directories, for example - "scp host:~user/file /tmp". The SFTP protocol has no native way to expand a ~user path. However, sftp-server(8) in OpenSSH 8.7 and later support a protocol extension "expand-path@openssh.com" to support this. Security sshd(8) from OpenSSH 6.2 through 8.7 failed to correctly initialise supplemental groups when executing an AuthorizedKeysCommand or AuthorizedPrincipalsCommand, where a AuthorizedKeysCommandUser or AuthorizedPrincipalsCommandUser directive has been set to run the command as a different user. Instead these commands would inherit the groups that sshd(8) was started with. Depending on system configuration, inherited groups may allow AuthorizedKeysCommand/AuthorizedPrincipalsCommand helper programs to gain unintended privilege. Neither AuthorizedKeysCommand nor AuthorizedPrincipalsCommand are enabled by default in sshd_config(5). Potentially-incompatible changes This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for --- lfs/openssh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lfs/openssh b/lfs/openssh index ec8ac1e55..1aea6cba9 100644 --- a/lfs/openssh +++ b/lfs/openssh @@ -24,7 +24,7 @@ include Config -VER = 8.7p1 +VER = 8.8p1 THISAPP = openssh-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -40,7 +40,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_MD5 = f545230799f131aecca04da56e61990a +$(DL_FILE)_MD5 = 8ce5f390958baeeab635aafd0ef41453 install : $(TARGET)