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

Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Hi Thomas,

On Sun, Jul 13, 2014 at 11:52:24AM +0800, Thomas Goirand wrote:
> On 07/12/2014 08:46 PM, Toni Mueller wrote:
> > As libressl is currently under
> > heavy development, it is imho not to be expected to have that stable ABI
> > you are asking for.
> Well, I don't agree with this view. If LibreSSL pretends to be a
> replacement for OpenSSL, then they should care about being ABI
> compatible,

but they are only partially compatible already. The one thing that
appears to stick out is that libressl has *no* support for egd, and on
purpose (ie, it will not come back). And the other is arc4random().

> so we can easily switch from one implementation to the
> other. Just like for MariaDB / MySQL in fact (not sure if these are
> still ABI compatible though). If that's not the case, then it looses a
> lot of its purpose. As Kurt wrote, GNUTLS becomes a better alternative then.

If your application does not use things which are deemed deprecated,
then it should be quite compatible, but by ripping out tons of old
stuff, they of course also break something, at some point. The whole API
becomes smaller simply because of that (I don't think this will be
offset by the added features in other areas, like adding better cipher

As for GnuTLS, all I read so far is that it requires a *lot* of work to
make a single application which has been developed together with
OpenSSL, compatible with GnuTLS, because apparently almost everything
differs to the point that it is unfeasible or impossible to have a
compatibility layer. That turns smaller adjustments in applications into
developing entirely different interfaces for each application, while
GnuTLS itself still lacks a lot of features. At the face of it, that
sounds like it is at least an order of magnitude more work, but likely
even much more than that. And add to that that GnuTLS apparently works
incorrectly almost half of the time (which translates to a significant
security *downgrade* in my eyes), there is a huge amount of work set for
those who would really try to fix it (ignoring the row between the
upstream author and the FSF aside for the moment).

> > OTOH, one guy already switched his entire Linux
> > system over, so far with no visible adverse effects.
> And then? This gives no clue if he had to rebuild everything that
> build-depended on OpenSSL...

That I don't know, but I have posed this question to the guy who made
that statement. I'll keep you posted.

> On 07/13/2014 01:15 AM, Russ Allbery wrote:
> > If you start using both for different packages, then you end up with
> > shared libraries conflicting over which libssl they want to use, and
> > then bad things start happening.
> Exactly! I fully agree with you on this.

I do not think that accidentically using one library when one wanted to
use the other will be an issue. FWIW, I've been told that a separate
"libressl.so" is in the making, and if so, binary incompatibility can be
taken for granted.

> This reminds me issues I had with mod-log-sql linked to MySQL and php
> as well, and when they were built against different versions... BOOM!
> I certainly do *not* want this kind of things to happen in Debian.
> Therefore, I'd very much prefer if we used OpenSSL *or* LibreSSL, but
> not have the choice between the 2, otherwise, that's a recipe for
> disaster.

Ummm... what was "BOOM" exactly, please? Because within a release,
OpenSSL ("letter") versions should all be compatible with each other.

> Please don't upload LibreSSL to Sid *ever*, unless we collectively
> decide that we are switching away from OpenSSL (and for which a
> discussion would have to start).

Well... as I said, I'm first and foremost planning to get it into
experimental, and then we can see what it really is, fix the packaging
etc.pp., and evaluate the package along the way. And while I hold the
OpenBSD developers in very high esteem, I am still a bit wary that the
package might be not as secure as we wish it to be, and therefore guess
that we want to evaluate the package thoroughly for some time before the
discussion about switching over can even start in a reasonable manner.

Having said that, I value all of your input, but feel not halfway as
much trigger happy as some of you seem to think I am.

Kind regards,

Reply to: