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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
