First Release of LibreSSL Portable Available

Yes - this release is intended for getting initial feedback, reports of build breaks, tell us where we messed up, etc. The release process is still being revised, but we wanted to get some initial feedback ahead of more polished future releases.

If you see LibreSSL 2.0.0 show up in your distro's stable package updates tomorrow, you should probably question the maintainers a little bit.

Well, libressl cannot a drop-in replacement for all cases since it does not provide all of the openssl symbols. When I tried rebuilding w3m, it became apparent that, for example, "RAND_egd" was missing.

> https://blog.hboeck.de/archives/851-LibreSSL-on-Gentoo.html lists a few problems you get when trying to use LibreSSL as a drop-in replacement. None were about version numbers.

Those in Dovecot and Net-SSLeay were.

OpenBSD may have chosen not to consider any ABI compatibility, but there would be a point to an incomplete ABI compatibility and if NOT then totally break it explicitly. The end goal is a more secure Free SSL implementation.

The obvious benefit to minimise incompatibility of the forks, is to allow independent review, cause cooperating improvements. like the various kernel git trees, rather than spreading developer resources more thinly, fragmenting, as has (unfortunately) happened with proliferation of Package management and Desktops.

Respecting ABI makes LibreSSL much easier to deploy as an experimental "security" replacement. They may not care taking "simple" narrow view for OpenBSD world, but I think that's a shame and liable to lead to greater and unecessary fragmentation. If they choose incompatibility, then #define all the func/struct's and make it total, which re-enables a choice at runtime if application developer chose to support it. That would help catch OpenSSL unwanted behaviour like re-defining system routines eg) malloc(3) generating link time conflicts.

A widely used "subset" ABI, would help enable OpenSSL developers to follow the lead also deprecating features in future "major" release, reducing the breadth of ABI, combating unwise freeping creaturism.

Pro. Sys. Admins. limit things for security frequently, deliberately breaking developer provided functionality, ulimit, SE Linux, chroot(2), network packet filters and all such, operate to enforce a subset of the POSIX ABI on programs. So really it's NOT scary or that unusual to have incomplete functionality, so long as it's not silent, mysterious breakage.

Programs using deprecated ciphers or those perl EGD dependant functions can be tested with drop-in preload library, and made to fail. Upstream have incentives to drop those features and use the intersection of original and forked SSL.

The alternative is asking distro packagers to configure applications, for both OpenSSL and LibreSSL or pick 1 for the distro, at configure time for a package. it's not like alternative logging daemons isolated by using IPC.

You can use in RPM, a virtual dependency which would most naturally be OpenSSL-1.0.1 in this case, but already Libre SSL is claiming 2.0, which can only be confusing as OpenSSL move to 1.0.2 or their own 2.0 which would again be incompatible with this LibreSSL 2.0 release.

However, if programs are needing to be modified, compiled & linked treating LibreSSL as a new API, then they make that single virtual symbol pointless, the alternatives will have to be pushed back a level, thus requiring double number of packages, or more likely ONLY supporting one of the alternatives. Choosing at install/link time, is static, not flexible and removes choice from end-user, not taking advantage of the dynamic loading at runtime of shared libraries.

The github project is good for reporting bugs.

We actually just fixed that issue I believe, thank you for the report!

As a convenience, the portable builds are already designed to use getentropy(2) if it exists on a system, and will prefer it over fallback mechanisms if it is available.

https://github.com/libressl-portable/portable/blob/master...

> As an addendum, as long as the deprecated sysctl continues to remain in the kernel (or at least remains until after the syscall is available), the voodoo should never be used, given your suggested order of entropy method calls.

AFAIK, with seccomp you can deny any syscall, making it return any errno you want, so an errant seccomp filter can in theory make the deprecated syscall fail with ENOSYS, even if it still exists in the kernel. So there exists at least one path which leads to the voodoo code: someone trying to sandbox code by making unexpected syscalls return the "inoffensive" -ENOSYS value, and not special-casing the sysctl syscall used by libressl, and something (perhaps the same seccomp filter) making the read of /dev/urandom fail.

I don't know how relevant that is, and I hope we never have to find out.

sysctl(2) in the kernel has not received any maintenance for years and when the bit-rot is sufficient the code will be torn out.

Seriously. No one cares. No one has ever cared. No one is going to care.

> CSPRNG calls are so deeply embedded within program logic that allowing the calls to fail in the normal course of execution (I.e. hitting a descriptor limit) is as sane as allowing unsigned addition to throw an error. It's simply not a sane interface. (Of course if the CSPRNG cannot be seeded it should abort the program)

What? You compare a single instruction issue with a call that does a long series of complex mathematical computations? With kernel interaction, entropy estimation, et. al.? Really?
If you write safety critical code that's written in a way that makes it impossible or infeasible to check for errors when using a CSPRNG: Please stay away from anything I will possibly use.

I don't have particularly strong feelings for/against getentropy() but this argument isn't doing it any favors.

> Also, chroot jails _should_ be within volumes mounted nodev. Nor should /proc be visible. The point of a chroot jail is to minimize kernel attack surface.

There's some value in that argument, but I think in reality the likelihood of opening new holes in software because /dev/null, /dev/urandom, /proc/self et al. aren't available is much higher than the security benefit.

Except that chroot is NOT a way to minimize an attack surface. The docs says so. And the root user has tons of ways to escape the chroot on Linux.

I'd be much more wary of a supposedly secure program not checking the return code of a function vital to its operation than an OS that deliberately and carefully returns that code in the first place.

Most programs in the world do not care about the randomness of a RNG. Only one type really does - those that handle public key encryption. If that program fails to check THE most important part of its initialisation and not at least throw out a warning string on stderr, then there's a bigger problem than how we signal that kind of error to it.

And, personally, I'd much prefer a warning of the "deprecation" kind in my logs from init if something goes wrong with that function, than any application crashing because it can't handle a particular syscall. If people are running secure systems and ignore printk messages that tell them the program used a function that it shouldn't, then they get what they deserve.

The "exceptions in C" thing is really just another dig at the language of choice in all these matters. There are plenty of ways for a C program to signal there was a problem - for instance failing any further calls until it has been properly initialised, setting a particular flag, returning a code to callers, etc. If people still AREN'T BOTHERING to check - whatever that method is - that's pretty much the death-knell to any kind of supposedly "secure" program, to my eyes.

The problem with sysctl is that RedHat has removed sysctl syscalls by default. sysctl(2) will _always_ fail on modern stock RedHat systems. It also fails on all the Gentoo systems I've tried, but I'm not sure if that's the default or a deliberate decision by our sysadmins. I only realized this recently as I use Debian and Debian-derivatives, and despite knowing about the kernel option I never fathomed that large vendors (especially ones which make claims to stable ABIs and APIs) would knowingly disable sysctl syscalls, considering all the software (like Tor) which depended on it at the time.

So sysctl({CTL_KERN, KERN_RANDOM, RANDOM_UUID}) is no longer a viable alternative. The only way to directly access kernel randomness is through an open reference to /dev/urandom or /proc/sys/kernel/random/uuid (the /proc sysctl interface).

That's the crux of the issue. If sysctl was still available then all would be well, other than some bickering over a sysctl versus a dedicated syscall interface.

In short: sysctl(2) is dead for all practical purposes on Linux. Now Linux behaves pretty much like Solaris, which never had sysctl (a later BSD extension). A lack of sysctl is one of the most annoying things about Solaris (although that's a long list).

OS X's arc4random also relies on /dev/urandom, since it copied an early FreeBSD implementation from before FreeBSD added sysctl({CTL_RAND, KERN_ARND}). And it will silently fail if /dev/urandom isn't visible when it initially seeds! And although I've long tried to support systems like OS X, Solaris, and FreeBSD<10.0 which lacked a kernel entropy syscall, I've always considered them second-class citizens in this regard, and willing to live with a disclaimer about possible issues. But now that Linux is second-class in this regard, it's a much more intolerable situation.