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

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


On Sat, Jul 12, 2014 at 07:43:44AM +0200, Marco d'Itri wrote:
> On Jul 12, Toni Mueller <support@oeko.net> wrote:
> > * Package name    : libressl
> I am highly doubtful at best.

in which respect, and why?

> What are your plans exactly?

My plan is to first build the package(s) and upload to experimental, so
people can start to play with it.

> Would it have the same SONAME of openssl and conflict+provide it?

I would like to make it co-installable with OpenSSL, but in general,
this should be a drop-in replacement until APIs really diverge in a
visible way. Yes, it would provide 'openssl', but I intend to place them
into a different directory, so you might have to use LD_PATH to get
them. Whether it has to conflict with openssl, I'll figure out that
later, if otherwise the case would arise that a binary might get libssl
from one package, and libcrypto from the other.

So far, it looks like a recompile could be necessary. But since the
upstream package has seen the light of day only yesterday (see
http://article.gmane.org/gmane.os.openbsd.announce/186 for the
announcement), things are not yet stable. For the technical side of the
discussion, you can read http://dir.gmane.org/gmane.os.openbsd.tech).

> Would it be a totally different library which packages would 
> build-depend on?

Packages currently build-depending on openssl should be able to
build-depend on "openssl-dev | libressl-dev". For recent versions of
OpenSSH, it already works, and another user writes: "Just switched my
slackware 14.1 box over to libressl instead of openssl and it's working
great so far, no problems at all." So I guess usability is already good.
But imho, it does have to stand the test of time, and receive
independent review, and much more exposure. Which is one reason why I
think it is a very good idea to expose it to the Debian and related

Kind regards,

Reply to: