LibreSSL is taking a beating, and that’s good

When I read about LibreSSL coming from the OpenBSD developers, my first impression was that it was a stunt. I did not change my impression of it drastically still. While I know at least one quite good OpenBSD developer, my impression of the whole set is still the same: we have different concepts of security, and their idea of “cruft” is completely out there for me. But this is a topic for some other time.

So seeing the amount of scrutiny from other who are, like me, skeptical of the OpenBSD people left on their own is a good news. It keeps them honest, as they say. But it also means that things that wouldn’t be otherwise understood by people not used to Linux don’t get shoved under the rug.

This is not idle musings: I still remember (but can’t find now) an article in which Theo boasted not ever having used Linux. And yet kept insisting that his operating system was clearly superior. I was honestly afraid that the way the fork-not-a-fork project was going to be handled was the same, I’m positively happy to be proven wrong up to now.

I actually have been thrilled to see that finally there is movement to replace the straight access to /dev/random and /dev/urandom: Ted’s patch to implement a getrandom() system call that can be made compatible with OpenBSD’s own getentropy() in user space. And even more I’m happy to see that at least one of the OpenBSD/LibreSSL developers pitching in to help shape the interface.

Dropping out the egd support made me puzzled for a moment, but then I realized that there is no point in using egd to feed the randomness to the process, you just need to feed entropy to the kernel, and let the process get it normally. I have had, unfortunately, quite a bit of experience with entropy-generating daemons, and I wonder if this might be the right time to suggest getting a new multi-source daemon out.

So a I going to just blindly trust the OpenBSD people because “they have a good track record”? No. And to anybody that suggest that you can take over lines and lines of code from someone else’s crypto-related project, remove a bunch of code that you think is useless, and have an immediate result, my request is to please stop working with software altogether.

Security Holes
Copyright © Randall Munroe.

I’m not saying that they would do it on purpose, or that they wouldn’t be trying to do the darndest to make LibreSSL a good replacement for OpenSSL. What I’m saying is that I don’t like the way, and the motives, the project was started from. And I think that a reality check, like the one they already got, was due and a good news.

On my side, once the library gets a bit more mileage I’ll be happy to run the tinderbox against it. For now, I’m re-gaining access to Excelsior after a bad kernel update, and I’ll just go and search with elfgrep for which binaries do use the egd functionalities and need to be patched, I’ll post it on Twitter/G+ once I have it. I know it’s not much, but this is what I can do.