On Sun, Oct 15, 2017 at 09:38:50PM +0200, Sebastian Andrzej Siewior wrote: > On 2017-10-13 15:30:13 [+0100], Colin Watson wrote: > > That's basically the last I recall hearing, and that they were trying to > > put pressure on OpenSSL upstream. > > I pinged upstream about the situation. I'm not sure if I made it worse > or not but I read something like "adding glue code to fetch and build > against libressl".
Thanks. We'll see how it goes. > > Does it help that OpenSSH only uses libcrypto, not libssh? If somebody > > were to split out the headers relevant to libcrypto into a separate > > package, then it'd be possible for openssh to build-depend on that. (I > > have no idea whether OpenSSL's headers are actually separable in this > > way.) > > Well it looks to me that upstream does not want to use accessor which > are requried by openssl 1.1 because they don't need them. This is what > it looks like to me right now. What makes you think that they would > accept a split like that? They would never use it libssh version, they > probably would bypass that layer if they made a protocol change which is > not yet covered by the library. I assume here you do not plat to > maintain that patch yourself. What? You've entirely misunderstood me. OpenSSH upstream *already* builds against only libcrypto and doesn't use libssl; I was suggesting that keeping around just libcrypto1.0 for a while would at least allow getting rid of libssl1.0 in Debian, although it would require packaging-level changes in OpenSSL to ship the files required to build against only libcrypto in a separate package. (Compare https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828475#39.) > I've been pointed out to another way to go I hope you like it: There is > PKIX-SSH [0]. I dislike the idea of switching to a fork even more than the idea of maintaining an enormous patch, I'm afraid - especially one that adds other features, making it a one-way change. -- Colin Watson [cjwat...@debian.org]
