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". > Also, Red Hat has maintainers paid to deal with forward-porting patches > in Fedora, whereas I'm normally doing it in my limited spare time. I > don't mind that for patches that are smaller or easier to handle, but in > my assessment this one would be fiddly to deal with as time goes on; the > GSSAPI key exchange patch we're already carrying is complicated enough > already and has sometimes caused delays of weeks or worse in me being > able to merge new upstream versions, so I don't want to exacerbate that > problem. yup. I understand that part. My part here is also covered by spare time. > There's the more complicated question of openssh-ssh1 as well, which is > frozen at an old upstream version now that upstream has dropped SSH1 > support. In that case I'm prepared to cherry-pick an upstream patch and > hunt down the necessary extra adjustments for SSH1 support, but I still > want it upstream first to minimise my liability to making > security-relevant mistakes. > > 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. I've been pointed out to another way to go I hope you like it: There is PKIX-SSH [0]. I am not sure if you are aware about that project but it was news to me. I knew only about dropbear as an alternative server. So, PKIX-SSH. This is an OpenSSH fork that compiles against OpenSSL 1.1. Some features over OpenSSH: - X.509 public key algorithms (legacy and RFC 6187). - fine tuning of allowed algorithms - FIPS (work with OpenSSL, Red Hat or Solaris fips-validated crypto-libraries) - keys from engine (cryptographic loadable module) - EC keys from PKCS#11 module (secure token) - LDAP based X.509 certificate store in addition to OpenSSL file and directory based. Used to build certificate chain. So from what I could find out is that that forks follows upstream and targets enterprices as a replacement of ssh.com (tectia-ssh). I tried to build it as a Debian package and noticed that you have a few patches on top. The gssapi patch is the largest one and from the description it does not look like it goes upstream any time. The pkix maintainer on the hand said the he would accept patches. So I have no idea if he takes it all but it does not look that bad actually :) [0] http://roumenpetrov.info/secsh/ Sebastian
