Re: Status of OpenSSL 1.1 support - Thoughts

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

 



Hi,

jpbion@xxxxxxxxxx wrote on Wed, Oct 18, 2017 at 08:11:05AM -0700:

> OpenSSH is a fantastic tool, but 
> I worry I will end up not being able to use it.

For you as an end-user, it seems extremely unlikely to me that it
might come to that.  LibreSSL and OpenSSH both have carefully
maintained portable releases that run on a wide variety of hardware
and operating systems, so if all else fails, you can simply compile
both for yourself.

Besides, no matter which operating system you are using, it seems
likely that the maintainers of the ports or packages on that system
will find *some* way to continue providing pre-compiled packages
to you.

> The real point of my note is: I don't see OpenSSL and LibreSSL merging 
> any time soon.

Unfortunately, i must admit that i fear you are right in that
respect.  As i explained previously, it is not quite easy to get
even harmless uncontroversial patches, like collections of bug fixes
in documentation, merged back from LibreSSL to OpenSSL, even if we
are willing to spend some time sending patches to OpenSSL.  So
cooperation is certainly less than ideal, which is (a smaller) part
of the reason why LibreSSL exists in the first place.

> Even if libreSSL puts in opaque structures, what if the 
> two teams view ways to handle the issues of 2018, and beyond 
> differently? Is API comparability, a goal at the start, going
> to remain a primary goal of both teams, especially if one of the
> two teams make choices seen as ill-founded by the other?

None of the teams will follow the other blindly, obviously, but
providing those reasonable interfaces that application software
actually uses in practice is an important goal of LibreSSL.

OpenSSL has a long history of providing very large numbers of
interfaces, of varying design quality, some of which are used
a lot and some of which are used rarely in practice or hardly
at all.

LibreSSL will not be able to keep up with the speed at which
OpenSSL keeps bloating the application programmer user interface,
and it doesn't really want to, because making the user interface
easier to understand and to use is among the project goals.

But that need not necessarily become a problem.  It only would if
large numbers of important application projects would start large-scale
use of new OpenSSL interfaces that LibreSSL considers so ill-designed
that they cannot be added to LibreSSL.  But frankly, if something
seems *that* disgusting to LibreSSL developers, i hope that others
will see the problems with it, too, and it won't get widespread use
in application software - problem solved...

In any case, it's of little use discussing all that now.  All we
can do is hope that everybody will stick to reasonable API design,
and try to sort out *specific* problems if it ever happens that
somebody makes a dubious decision.

> As a result, i worry if it will be possible to maintain software,
> over time, that supports both variants of SSL stack.

Keeping that possible, at least for many years, and at the same time
remaining reasonably compatible with BoringSSL as well, is among the 
goals of LibreSSL for sure.  Of course, nobody can reasonably talk
about the remote future, and i cannot answer for OpenSSL in any way.

In the worst case, if OpenSSL would unfortunately choose to burn
all bridges and become completely incompatible with its own past,
that still wouldn't be a very big problem for OpenSSH.  At that
point, OpenSSH would simply be forced to require LibreSSL as a hard
dependency and drop all support for OpenSSL, but you could still
rely on OpenSSH, of course.

Yours,
  Ingo
_______________________________________________
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