Why is libresslpreferable to openssl?

@peti Personally I would prefer LibreSSL because their aim is to clean up the code in OpenSSL and make it at least somewhat maintainable, which I, having unfortunately spent some time looking at the original code, can only welcome.
See also (very informal) http://www.openbsd.org/papers/bsdcan14-libressl/mgp00001.html -- it's very biased towards LibreSSL of course, but it shows main pain points.

libressl got a security advisory a few days ago (doesn't affect openssl) http://seclists.org/oss-sec/2015/q4/87

Generally openssl has had much more CVEs than openssl since libressl forking off and libressl aim to clean up a lot of the old cruft from which is totally worthless now.

See https://wiki.freebsd.org/LibreSSL for a list of vulnerabilities.

How do other distributions handle this? Does anyone else prefer libressl over openssl?

I think no, apart from OpenBSD but they don't qualify as a Linux distribution ^_^.

I can't even find the package in major distros, but I suppose it would be nontrivial for them to have a different version of libssl along with the default. Void Linux sounds as a Linux distribution, though https://en.wikipedia.org/wiki/LibreSSL#Adoption

I also remember several Arch Linux packages in AUR and guides for replacing OpenSSL with LibreSSL on it; the biggest problem is, as @vcunat said, a big difficulty in having two libssl versions -- some packages use OpenSSL APIs that LibreSSL has discontinued. This is a problem that Nix solves elegantly.

@abbradar up to libressl 2.2* there should be no problems with discontinued APIs, only 2.3 removes all SSLv3 code which I have seen break 2 packages so far, one fixed on master (#10463), the other open in #10465

I personally would prefer using libressl 2.2.4 as default for now in NixOS as that is the latest stable release, 2.3 being the current snapshot releases.

Might I suggest to first only introduce pkgs.libssl as an abstraction for "a libssl-compatible library" ? Reaching consensus for this might be quicker than mixing both items. This branch touches a lot of packages and is likely expensive to maintain. I believe that there is also more that two choices: gnutls and boringssl also come to mind (although boringssl seem like a pain to bootstrap).

In regards to pkgs.libss. Is aliasing a good-enough solution or do we need a mechanism to fallback to openssl for well-known broken libraries ?
Also related, how do we prevent package authors to link openssl instead of libssl when creating new packages ?

👍

Void Linux sounds as a Linux distribution, though

Also see Gentoo's overlay.

How do we prevent package authors to link openssl instead of libssl when creating new packages ?

This seems impossible; openssl is what is in all the documentation etc., NixOS is not powerful enough to make everyone switch to using libssl instead.

Here's how I would allow libressl:

openssl-official = <current openssl>
openssl = if config.useLibressl or false then libressl else openssl-official;

openssl is a generic[1] term for both the official OpenSSL library and its forks, and openssl-official can be used for packages that don't work with libressl, like so:

mypkg = callPackage ../development/mypkg { openssl = openssl-official; };

[1] Generic terms are generic, not the first user owns them -- Kay Sievers

This seems impossible; openssl is what is in all the documentation etc., NixOS is not powerful enough to make everyone switch to using libssl instead.

We can always solve the problem with another layer of indirection :p Maybe pkgs.libssl would become a function that takes a white and a black list and returns the right derivation. Then all SSL libraries are removed from the top-level and then the only way to access them is trough that function.

That being said, I don't think that most people will want to switch libraries. After all you need the recompile half of the programs in the system and don't benefit from the hydra builds anymore.

I like your idea of taking openssl as the generic name, this is the library I would look for when developing packages and not libssl. Then I would read the all-packages.nix and understand what's going on from a comment. Just having openssl = libressl is probably enough as it can be changed with overrides and is not likely to be frequent.

I like your idea of taking openssl as the generic name

Me too. The switch shouldn't involve touching hundreds of expressions. That tends to create merge interactions, e.g. with the closure-size branch. And there's not just libssl but libcrypto in there, too.

The line openssl = if ..... is probably unnecessary, as packageOverrides seems perfectly suited for such changes.

Indeed. I don't see a reason for this change, packageOverrides is perfectly enough.

Also for the discussion and a friendly reminder, that libressl and all other alternatives have seen less vulnerabilities because they are much less used than openssl.

We have stopped using this ourselves and changed to an approach overriding openssl with libressl_2_3 with the help of #11673 and #11653.

Then one can either set openssl_1_0_1 explicitly on packages that need ABI compatibility or patching software that relies on obsolete libssl code (#11674)

Okay, thanks for all the feedback. We will move forward by keeping the openssl attribute name for generic openssl API compatible implementations.