Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
On Jul 12, Toni Mueller <support@oeko.net> wrote:
> 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?
I think some people are jumping ahead to "oh no! we're replacing
OpenSSL?". That's something to be have some rough plan for in case
we eventually want to do that. But for now I don't think it's a
reason not to package it or even allow it into sid/testing.
> > 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.
It is definitely an interesting piece of software, with some different
design choices being made here and there. It even adds some new
features (new ciphers and elliptic curves for example) and the utilities
are useful standalone (such as for an SSL CA).
People can start to play around with it and maybe to try to rebuild
packages against it locally. It couldn't be a drop-in replacement
for OpenSSL's libssl and libcrypto because the ABI will differ. The
source API is being kept as similar as possible so in theory:
> Packages currently build-depending on openssl should be able to
> build-depend on "openssl-dev | libressl-dev".
that sounds like it should just work. Or otherwise, it could reveal
if a package uses some 'unsafe' part of the API that OpenBSD has removed
during their cleanup. Any incompatibilities or run-time differences are
likely interesting to both SSL libraries as it could indicate a bug
somewhere.
Probably only a minority of people would want to rebuild many packages
on their system against LibreSSL. But having it packaged, and
co-installable helps people who want to do this. Similarly there is
support in the Exim packaging to rebuild with OpenSSL instead of GnuTLS.
Regards,
--
Steven Chamberlain
steven@pyro.eu.org
Reply to: