Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
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
> 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:
> 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
It still gets 5 out of 16 answers wrong, as per the comparison sheet