]> git.ipfire.org Git - thirdparty/openssh-portable.git/commit
upstream: As defined in the RFC, the SSH protocol has negotiable
authorderaadt@openbsd.org <deraadt@openbsd.org>
Fri, 23 Aug 2024 04:51:00 +0000 (04:51 +0000)
committerDamien Miller <djm@mindrot.org>
Mon, 26 Aug 2024 23:05:43 +0000 (09:05 +1000)
commit10ccf611ab8ecba9ce6b0548c5ccd8c1220baf92
treece6dc0c5c4f0f624323c54a2b5b260e1c078a673
parentaee54878255d71bf93aa6e91bbd4eb1825c0d1b9
upstream: As defined in the RFC, the SSH protocol has negotiable

compression support (which is requested as the name "zlib"). Compression
starts very early in the session. Relative early in OpenSSH lifetime, privsep
was added to sshd, and this required a shared-memory hack so the two
processes could see what was going on in the dataflow.  This shared-memory
hack was soon recognized as a tremendous complexity risk, because it put libz
(which very much trusts it's memory) in a dangerous place, and a new option
("zlib@openssh.com") was added begins compression after authentication (aka
delayed-compression).  That change also permitted removal of the
shared-memory hack. Despite removal from the server, the old "zlib" support
remained in the client, to allow negotiation with non-OpenSSH daemons which
lack the delayed-compression option. This commit deletes support for the
older "zlib" option in the client. It reduces our featureset in a small way,
and encourages other servers to move to a better design. The SSH protocol is
different enough that compressed-key-material attacks like BEAST are
unlikely, but who wants to take the chance? We encourage other ssh servers
who care about optional compression support to add delayed-zlib support.
(Some already do "zlib@openssh.com") ok djm markus

OpenBSD-Commit-ID: 6df986f38e4ab389f795a6e39e7c6857a763ba72
cipher.c
kex.c
kex.h
packet.c
readconf.c