Re: Status of OpenSSL 1.1 support - Thoughts

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



Hello,


On Wed, Oct 18, 2017 at 6:36 PM, Ingo Schwarze <schwarze@xxxxxxx> wrote:
> Hi Emmanuel,
>
> Emmanuel Deloget wrote on Wed, Oct 18, 2017 at 05:45:40PM +0200:

<snip>

>> I'd volonteer to do this but given the gigantism of the task, any help
>> would be appreciated (not to mention that even if Joel agrees with the
>> idea of having the 1.1 API in LibreSSL, that does not mean he would
>> agree with my strategy).
>
> You could offer your help for providing that migration path to the
> OpenSSL project, if you feel qualified and willing to provide such
> help.  I think you should definitely use the expertise of the OpenSSL
> developers to make sure that providing the migration path doesn't
> introduce bugs and vulnerabilities, and avoid working as a lone
> wolf if possible.

Working as a lone wolf on this project is definitely not what I want
to do. However, I can propose the first (simple) patches and hopefully
someone else will join the effort once it has started :)

>> But at the same time, some ditributions are phasing out OpenSSL 1.0.2
>> and are integrating OpenSSL 1.1 while at the same time some supported
>> LTS distributions still rely on older OpenSSL versions. So for a
>> period of time you'll have to be compatible with both, whether you
>> like it or not. The question is then: is it up to you to be compatible
>> with both,
>
> The OpenSSH project simply doesn't have the manpower to maintain
> compatibility with both at the same time, and even if it had, doing
> so would compromise the central project goal of security through
> simplicity and diligence.

Ok.

>> or is it up to distributors to provide compatibilty?
>
> That will be beyond the means of many distributors, in which case
> they either need to use OpenSSL-1.0 or LibreSSL for OpenSSH.
>
> Even for those distributors who can afford the required manpower,
> i consider attempting to maintain a 3000+ line vendor patch risky,
> and maintaining a non-official compat layer risky as well.  Quite
> respectable vendors have screwed up with three-line patches in the
> past, how can anybody feel confident about a 3000-line vendor patch?
> How sure can you feel that none of these 3000 lines causes non-obvious
> problems?  That also answers the question Jakub Jelen asked why i
> would feel uncomfortable about using Fedora.
>
> Yours,
>   Ingo

Let's restate the full goal here :

* first, LibreSSL should integrate the OpenSSL 1.1 API
* second, it should mark the replaced interface as deprecated
* third, make OpenSSH use the new interface

That sounds like a manageable list of goals -- i.e. one that can prove
to be completed before the EOL of OpenSSL 1.0.2 in Dec. 2019.

First problem to overcome is that LibreSSL is released every 6 month,
so the work is probably going to be split on two or more releases. As
a consequence, the transition work cannot start on OpenSSH before the
next LibreSSL release (i.e. version 2.7.0 that should be released in
May) and will probably take a long time.

For distributors and maintainers out there, that means:

* distributions that decided to phase out OpenSSL 1.0.2 in favor of
OpenSSL 1.1 will have to support an OpenSSH patch that will grow
smaller and smaller at each release.
* distributions that decided to keep OpenSSL 1.0.2 or to link OpenSSH
with LibreSSL have nothing to do, and will be ready to phase out
OpenSSL 1.0.2 at EOL time.

Is it something that apear to be manageable?

BTW, do you know any other software that uses the LibreSSL API the
same way OpenSSH is using it (i.e. LibreSSL is the primary target,
OpenSSL compatibility is of lesser importance)?

BR,

-- Emmanuel Deloget
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux