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
On Tue 2016-11-15 08:02:06 +0900, Damien Miller wrote:> 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.FWIW, i consider nettle to be a compelling FLOSS crypto primitive library. It doesn't provide TLS or SSL, but i don't think that's anything that OpenSSH would care about. https://www.lysator.liu.se/~nisse/nettle/ --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 962 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20161115/1b5d2a66/attachment-0001.bin>
On 11/15/2016 12:02 AM, Damien Miller wrote:> 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?Yes, you got a message off-the-list from Tomas Mraz, our OpenSSL maintainer, one week ago. The OpenSSL certainly wants to resolve these issues from their side (compat library in addition to 1.0.2 from OpenSSL side). But that will not help us with compatibility against LibreSSL if I see right. Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat
On Tue, 15 Nov 2016, Jakub Jelen wrote:> On 11/15/2016 12:02 AM, Damien Miller wrote: > > 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? > > Yes, you got a message off-the-list from Tomas Mraz, our OpenSSL maintainer, > one week ago. The OpenSSL certainly wants to resolve these issues from their > side (compat library in addition to 1.0.2 from OpenSSL side). But that will > not help us with compatibility against LibreSSL if I see right.For my part, I'm going to wait a while to see what migration improvements come from OpenSSL and I don't plan on merging any changes to support 1.1.x until there's a better story. I'm sure that if OpenSSL come up with a cleaner way for their users to support 1.0.x and 1.1.x then it will be easier to convince Libre/BoringSSL to follow suit. -d
Jakub Jelen wrote:> On 11/15/2016 12:02 AM, Damien Miller wrote: >> 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? > Yes, you got a message off-the-list from Tomas Mraz, our OpenSSL > maintainer, one week ago. The OpenSSL certainly wants to resolve these > issues from their side (compat library in addition to 1.0.2 from > OpenSSL side).I don't think that this is so important. Each project has specific use of crypto library and is not so difficult to write compatibility layer. I know a number of projects that already has such layer.> But that will not help us with compatibility against LibreSSL if I see > right.If compatibility layer is written properly OpenSSL compatible libraries will be supported as well. For instance PKIX-SSH mainly tests for the presence of each feature and as result supported builds with various OpenSSL versions, including FIPS or Kerberos enable. Such tests ensure builds with OpenSSL compatible libraries. Using cryptographic library A or B version c or d and etc. depends of many things. One criteria is that know defects are fixed, but this is off-topic to OpenSSL API 1.1 support. Just one remark: Long time ago OpenSSL team announce plan to hide structures to ensure better compatibility between releases. Team miss 1.0 release but now this is fact. Regards, Roumen Petrov -- Secure shell with X.509 certificate support http://roumenpetrov.info/secsh/