On Tue, 12 Jul 2022, Darren Tucker wrote:> Hi. > > This applies on top of my previous patch cleaning up libcrypt and stops > linking scp, sftp and sftp-server against libcrypto. Why do this? > Well for one reason these components sometimes get used independently > of ssh/sshd (eg in OpenWRT where they can be used with Dropbear) and > it'd be nice if I could have sftp on space constrained devices without > the currently-required but not strictly necessary additional libraries. > > The same thing can be done with zlib but that's the next patch.IIRC we linked libcrypto because some linkers were not smart enough to elide references to libcrypto coming from unused functions in libssh It's possible that I'm wrong/outdated though
Demi Marie Obenour
2022-Jul-13 07:56 UTC
Don't link sftp, sftp-server or scp with libcrypto
On 7/13/22 00:56, Damien Miller wrote:> On Tue, 12 Jul 2022, Darren Tucker wrote: > >> Hi. >> >> This applies on top of my previous patch cleaning up libcrypt and stops >> linking scp, sftp and sftp-server against libcrypto. Why do this? >> Well for one reason these components sometimes get used independently >> of ssh/sshd (eg in OpenWRT where they can be used with Dropbear) and >> it'd be nice if I could have sftp on space constrained devices without >> the currently-required but not strictly necessary additional libraries. >> >> The same thing can be done with zlib but that's the next patch. > > IIRC we linked libcrypto because some linkers were not smart enough to > elide references to libcrypto coming from unused functions in libssh > > It's possible that I'm wrong/outdated thoughThat reminds me: is there any chance that OpenSSH?s SSH client code could be made into a library that other code could use as well? Having to spawn a child process is a bit annoying, and I would like to be able to use all of ssh(1)?s features. -- Sincerely, Demi Marie Obenour (she/her/hers) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xB288B55FFF9C22C1.asc Type: application/pgp-keys Size: 4885 bytes Desc: OpenPGP public key URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220713/661ca69a/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220713/661ca69a/attachment.asc>
On Wed, 13 Jul 2022 at 14:56, Damien Miller <djm at mindrot.org> wrote:> On Tue, 12 Jul 2022, Darren Tucker wrote: > > This applies on top of my previous patch cleaning up libcrypt and stops > > linking scp, sftp and sftp-server against libcrypto.[...]> IIRC we linked libcrypto because some linkers were not smart enough to > elide references to libcrypto coming from unused functions in libssh > It's possible that I'm wrong/outdated thoughHaving done some experimentation I now think our understanding of that was wrong. Instead, I think the differentiating factor was whether or not the platform depended on OpenSSL for getrandom and/or arc4random. scp, sftp and sftp-server call seed_rng() even though they don't actually use the RNG, and in doing so pull in dependencies on libcrypto via entropy.c and port-prngd.c. After removing those, this seems to work on all of the platforms in the test zoo (at least so far, the tests are still running on the slower ones) and the resulting binaries do not need to link libcrypto or libz against the scp, sftp and sftp-server binaries. https://github.com/openssh/openssh-portable/compare/master...daztucker:openssh-portable:master -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.