From: Adolf Belka <adolf.belka@ipfire.org>
To: development@lists.ipfire.org
Subject: [PATCH] openssh: Update to version 8.8p1
Date: Mon, 27 Sep 2021 17:33:59 +0200 [thread overview]
Message-ID: <20210927153359.1500601-1-adolf.belka@ipfire.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 4251 bytes --]
- 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(a)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 <USD$50K [1]
For most users, this change should be invisible and there is
no need to replace ssh-rsa keys. OpenSSH has supported RFC8332
RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys
will automatically use the stronger algorithm where possible.
Changes since OpenSSH 8.7p1
This release is motivated primarily by the above deprecation and
security fix.
New features
* ssh(1): allow the ssh_config(5) CanonicalizePermittedCNAMEs
directive to accept a "none" argument to specify the default
behaviour.
Bugfixes
* scp(1): when using the SFTP protocol, continue transferring files
after a transfer error occurs, better matching original scp/rcp
behaviour.
* ssh(1): fixed a number of memory leaks in multiplexing,
* ssh-keygen(1): avoid crash when using the -Y find-principals
command.
* A number of documentation and manual improvements, including
bz#3340, PR139, PR215, PR241, PR257
Portability
* ssh-agent(1): on FreeBSD, use procctl to disable ptrace(2)
* ssh(1)/sshd(8): some fixes to the pselect(2) replacement
compatibility code. bz#3345
Signed-off-by: Adolf Belka <adolf.belka(a)ipfire.org>
---
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)
--
2.33.0
reply other threads:[~2021-09-27 15:33 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210927153359.1500601-1-adolf.belka@ipfire.org \
--to=adolf.belka@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox