Red Hat Bugzilla – Bug 20204
Openssh breaks if openssl-0.9.6 is installed
Last modified: 2008-05-01 11:37:59 EDT
The openssh SRPM/RPMs need to have a requirement on openssl < 0.9.6.
The API data structures for some of the EVP_ calls in libcrypto.so.0
were changed drastically, and will not work at all with any applications
built against openssl-0.9.5a (or lower).
I also have a patch that enables the sftp server so openssh may be used
with the commercial sshwin2 sftp client. Contact me if you are interested.
$ diff openssl.spec.rh openssl.spec
< Requires: openssl >= 0.9.5a
> Requires: openssl >= 0.9.5a, openssl < 0.9.6
Created attachment 4916 [details]
Created attachment 4917 [details]
sftp source patch (the last attachment was the new spec file).
If binary compatibility is broken, then we need to bump the soname when we add
0.9.6 to the build system, which will properly catch binary-incompatibility
problems (lack of time to verify this either way is why it's not already in Raw
Hide). If sftp isn't in the default portable distribution of OpenSSH, I'm also
loathe to add it.
That sftp-server is from the normal distribution. It's also included in OpenSSH-2.3.0p1 released today.
The sftp server will be in the 2.3.0p1 errata. I'll leave this one open until
we get 0.9.6 into Raw Hide, along with the various rebuilds it requires.
Getting 0.9.6 into Raw Hide will require bumping the shared object's SONAME,
which is going to require adding a compatibility package for with the older
version of the shared library to keep third-party apps working, in addition to
numerous rebuilds in the distribution itself.
You will have to do this for every release then - the OpenSSL people are not
promising binary compat until at lease 1.0.0.
Exactly. It's a mess, and we're not going to go there for now. (As an aside,
this almost certainly explains why mysterious problems show up when J. Random
User runs openssh using openssl packages other than the ones they were built