Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
Hi Jeroen,
On Sun, Jul 13, 2014 at 12:22:49PM +0200, Jeroen Dekkers wrote:
> At Sat, 12 Jul 2014 14:46:45 +0200, Toni Mueller wrote:
> > Ok, but for whatever reason, they have an imho not as shiny track
> > record, as has OpenBSD. Which is no wonder, given all the revelations we
> > have had recently, but hey, sometimes one has to make a decision.
>
> OpenSSL was part of OpenBSD before they created the LibreSSL fork, so
> how isn't OpenSSL part of the OpenBSD track record?
it is in the way that they include it, and it also contributed a
significant amount of all patches that were required over the years, but
the typical way OpenBSD operates - from my perspective - is, they
include something (eg. Sendmail), and once they get fed up with it for
whatever reason, unless they find something acceptable out there (eg.
nginx instead of Apache, or nsd(?)+unbound instead of BIND), they start
to roll their own. A few releases later, the old stuff is being demoted
or removed entirely (eg. for RAIDframe -> softraid, the switchover
period where you could choose was more than four years, afair). Such
changes do happen in a disruptive manner, as there is usually nothing
that aids you in converting your setup from the old to the new software.
> It depends on how you look at it. If you see the OpenSSL API as
> something that isn't really well designed then other libraries not
> copying the API is actually a good thing.
Yes and no, but if it is more than ten times the amount of work, it is
likely never getting done, for the simple reason that everyone is
lacking resources.
> You forget one of the big problems with OpenSSL that LibreSSL doesn't
> fix: the license.
Granted. Due to the amount of inherited code, it can't. We'll see how
things evolve as the amount of inherited code will dwindle.
> It actually makes the mess even bigger, given that
> some of the GPL exceptions only talk about "the OpenSSL library" and
> don't exempt OpenSSL-derived code. So even if LibreSSL is a drop-in
> for OpenSSL we can't replace OpenSSL with LibreSSL for those projects.
Yes. Thanks for pointing this out.
> You also forget to list two other TLS libraries:
>
> * NSS, in my opinion the biggest downside of NSS is that it includes
> NSPR. This both increases the code size a lot and makes the API less
> nice if I remember correctly.
Hmmm... yes. I was under the impression that not very many people were
using it, but looking at my system, NSS + NSPR ~ 3,5MB, while
libssl1.0.0 comes in at ~3MB. Add ~1MB for sqlite3 and zlib1g in the
case of NSS...
> * PolarSSL, which I really like from a technical point of
> view. Featurewise it is pretty complete (the only major feature it
> doesn't implement is DTLS AFAICS), while being one tenth the size of
> OpenSSL / GnuTLS:
> https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Code_size_and_dependencies
> PolarSSL is also used by OpenVPN-NL, the hardened OpenVPN version
> that is used by the Dutch government.
> The downsides are that it looks like it doesn't have a stable API
> and contributing needs copyright assignment because it is
> dual-licensed.
It still gets 5 out of 16 answers wrong, as per the comparison sheet
included here:
https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf
Kind regards,
--Toni++
Reply to: