On Wed, 2 Nov 2016, Stuart Henderson wrote:> On 2016-11-02, Jakub Jelen <jjelen at redhat.com> wrote: > > The current set of patches are rebased on current upstream is attached > > with few more tweaks needed to build, pass testsuite and make it work. > > The upstream review and insight would be helpful. > > Since these are going to break things with LibreSSL, I doubt they'll be > acceptable as-is.This is the nub of the problem: upstream (OpenBSD) OpenSSH targets LibreSSL natively (it's also used by Apple for their OS X builds). If we pick up the 1.1.0 patch, we'd probably have to do it in portable because there's little point in patching OpenBSD for API that doesn't exist there. I don't want to have to carry such a major divergence in just the portable tree. I don't know what LibreSSL's plans are wrt the 1.1.x API, but convincing them to adopt it would remove much of the problem. It's disappointing though that OpenSSL didn't see fit to write their own set of 1.0.x->1.1.x API shims and ship it alongside 1.0.x releases. It would have made the transition easier for everyone I think. -d
On Thu, Nov 03, 2016 at 09:33:23AM +1100, Damien Miller wrote:>It's disappointing though that OpenSSL didn't see fit to write their own >set of 1.0.x->1.1.x API shims and ship it alongside 1.0.x releases. It >would have made the transition easier for everyone I think.Given how much flack they got from various quarters, including in particular the libressl folks, for carrying "too much legacy baggage" that would have ironic if nothing else. All that aside, I'm not entirely clear on why there's a pressing need to link openssh against openssl 1.1 instead of just linking it to 1.0; 1.0.2 is actually scheduled to be supported for longer than 1.1.0. Mike Stone
On Wed, 2 Nov 2016, Michael Stone wrote:> On Thu, Nov 03, 2016 at 09:33:23AM +1100, Damien Miller wrote: > > It's disappointing though that OpenSSL didn't see fit to write their own > > set of 1.0.x->1.1.x API shims and ship it alongside 1.0.x releases. It > > would have made the transition easier for everyone I think. > > Given how much flack they got from various quarters, including in > particular the libressl folks, for carrying "too much legacy baggage" that > would have ironic if nothing else.I think you misunderstand: I'm not suggesting they carry 1.0.x API in 1.1.x (that would be self-defeating), but providing standard forward- compat code in 1.0.x so everyone else doesn't have to write their own. IMO nobody is in a better position to write said compat code than the OpenSSL developers and forcing application developers to write them greatly multiplies the number of shim implementations and thus the likelihood of bugs in one or more of them. -d
On 11/02/2016 11:33 PM, Damien Miller wrote:> On Wed, 2 Nov 2016, Stuart Henderson wrote: > >> On 2016-11-02, Jakub Jelen <jjelen at redhat.com> wrote: >>> The current set of patches are rebased on current upstream is attached >>> with few more tweaks needed to build, pass testsuite and make it work. >>> The upstream review and insight would be helpful. >> Since these are going to break things with LibreSSL, I doubt they'll be >> acceptable as-is. > This is the nub of the problem: upstream (OpenBSD) OpenSSH targets > LibreSSL natively (it's also used by Apple for their OS X builds). If we > pick up the 1.1.0 patch, we'd probably have to do it in portable because > there's little point in patching OpenBSD for API that doesn't exist > there. I don't want to have to carry such a major divergence in just the > portable tree.Thank you for the comments. I understand the upstream directions and that the OpenSSL step is not ideal. The distros will probably have to carry these patches until the changes will settle down a bit. Other possible solution we were discussing here was implementation of non-OpenSSL specific abstract layer for crypto operations, which would allow implementation of cryto-library specific bits in separate file (unlike current situation with calls all over the place) and would possibly allow different crypto library providers, similar way how the audit is handled at this moment. It would also abstract the code from the changes in one or the other crypto library interface. Would something like this be acceptable for OpenSSH upstream? Kind regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat
Dave Shariff Yadallee - System Administrator a.k.a. The Root of the Problem
2016-Nov-14 17:31 UTC
OpenSSL 1.1.0 support
On Mon, Nov 14, 2016 at 04:36:28PM +0100, Jakub Jelen wrote:> On 11/02/2016 11:33 PM, Damien Miller wrote: > > On Wed, 2 Nov 2016, Stuart Henderson wrote: > > > >> On 2016-11-02, Jakub Jelen <jjelen at redhat.com> wrote: > >>> The current set of patches are rebased on current upstream is attached > >>> with few more tweaks needed to build, pass testsuite and make it work. > >>> The upstream review and insight would be helpful. > >> Since these are going to break things with LibreSSL, I doubt they'll be > >> acceptable as-is. > > This is the nub of the problem: upstream (OpenBSD) OpenSSH targets > > LibreSSL natively (it's also used by Apple for their OS X builds). If we > > pick up the 1.1.0 patch, we'd probably have to do it in portable because > > there's little point in patching OpenBSD for API that doesn't exist > > there. I don't want to have to carry such a major divergence in just the > > portable tree. > > Thank you for the comments. I understand the upstream directions and > that the OpenSSL step is not ideal. The distros will probably have to > carry these patches until the changes will settle down a bit. > > Other possible solution we were discussing here was implementation of > non-OpenSSL specific abstract layer for crypto operations, which would > allow implementation of cryto-library specific bits in separate file > (unlike current situation with calls all over the place) and would > possibly allow different crypto library providers, similar way how the > audit is handled at this moment. It would also abstract the code from > the changes in one or the other crypto library interface. Would > something like this be acceptable for OpenSSH upstream? >All SSL developers have to take into account 1) LibreSSL 2) Openssl 1.0.X and below and 3) OPenssl 1.1 + So stop stop living in the past and march towards the future.> Kind regards, > > -- > Jakub Jelen > Software Engineer > Security Technologies > Red Hat > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev-- For effective Internet Etiquette and communications read http://catb.org/jargon/html/T/top-post.html, http://idallen.com/topposting.html & http://www.caliburn.nl/topposting.html
On Mon, 14 Nov 2016, Jakub Jelen wrote:> Thank you for the comments. I understand the upstream directions and > that the OpenSSL step is not ideal. The distros will probably have to > carry these patches until the changes will settle down a bit.AFAIK Red Hat employs at least one OpenSSL maintainer. What is their view on this situation?> Other possible solution we were discussing here was implementation of > non-OpenSSL specific abstract layer for crypto operations, which would > allow implementation of cryto-library specific bits in separate file > (unlike current situation with calls all over the place) and would > possibly allow different crypto library providers, similar way how > the audit is handled at this moment. It would also abstract the code > from the changes in one or the other crypto library interface. Would > something like this be acceptable for OpenSSH upstream?That's an option that involves a heap of work. I've toyed with it for a while now, but haven't been motivated enough to start it. Part of the reason is that there has been no compelling alternative open- source crypto library to justify the effort of building the abstraction layer. I don't really feel like OpenSSL 1.1 is sufficiently different to justify it either. -d