I remember so many people in the open source world angry or annoyed with the OpenBSD team for forking LibreSSL. The fact is it's more than a year later, several more high-risk vulnerabilities discovered, and OpenSSL has yet to make any noticable changes. Meanwhile those same vulnerabilities were fixed in LibreSSL due to code cleanup and removal.[1]
No matter how you feel about the forking or the openbsd team, there is something to be learned here. There are times when forking, deleting old code, and major clean-ups can be very useful strategies. Sunk cost bias can be an enemy of progress.
I'm curious what circles you run in in the open source world. In my little corner of it, most everyone had nothing but excitement and support for LibreSSL.
I was employed at a large open-source organization at the time of the fork. A conversation I participated in was specifically along the lines of (broad paraphrasing here) "They should be contributing their changes back to OpenSSL versus forking".
While attending a security conference in Vancouver earlier this year, someone commented that they thought the OpenBSD team was childish for forking LibreSSL, and several people chimed in with agreement.
Of course this is all hear-say for you, and your experiences may vary. I've met more than a handful of people who did not like the fork. There are lots of people in the world, and they all have different opinions.
> "They should be contributing their changes back to OpenSSL versus forking".
I suppose that this attitude comes from people who think the fork happened solely because of Heartbleed, when the real reasons are a little more intricate[0] but the straw that broke the camels back was the discovery that OpenSSL had known about certain bugs and let patches to fix them rot in their bug tracker for years. It's hard to contribute changes back when a project won't take patches.
OpenSSL could have taken LibreSSL's changes if they wanted to, it's all public in the OpenBSD source tree, but they haven't.
One of the big things they did was cut out enormous amounts of legacy code. Code that someone somewhere might be using. Since they were basically just making LibreSSL for themselves they didn't have to care about that and could be much more free with the changes.
The OpenSSL developers would have a much tougher time dropping MSDOS and VMS and OS/360 support because there are still a couple of people who need it.
They didn't make it 'just' for themselves - it supports Windows, Linux and and Mac OS X on various (modern) architecture also.
I think at some point, if you've got a legacy application running on such an old platform, the cost of maintaining your own fork of libraries like OpenSSL has to fall on you eventually.
Although OpenSSL themselves continuing to maintain these ancient ports is admirable in a way, the unmaintainability it has caused to the code base as a whole is a serious problem that has reduced security for everyone.
Having spent years working with openssl code, there's nothing you can do to save it but take a rusty axe to it.
Every horrifying thing in there is justifiable because "someone might be using it". Not enough reason to risk the security of every net-connected Unix over.
So, forking is pretty much the only way to do proper code cleanup in a timely fashion, right?
If you don't, people still clamor for legacy support and bug-for-bug compatibility. A fork is the only way of truly signalling "We aren't going to support our old mistakes anymore."
New features don't need forks, but cleaning up raging stupid and cruft does.
IMHO, there is a time an place for everything. Sometimes forking is a good idea sometimes not.
When you want to make idealogcal changes to an existing codebase that does not mesh with the idealologies of the maintainer(s), forking is a great way to make your changes happen. Time will tell if your ideas were good ones. That and how well your maintain and promote your fork. :-)
In the case of OpenSSL vs LibreSSL, it appears the OpenBSD team made a great call and they are making it work really well. As for if anyone else agrees and adopts it, only time will tell.
I do seem to recall some complaining about the tone the OpenBSD developers used, but they where not really getting anywhere by being nice either. Also some complaining about them not helping to fix OpenSSL instead.
I can only echo your sentiments. There seemed to be some skepticism about their attitude (what with the Comic Sans thing :)), but everyone in my circles at least respects the OpenBSD team's technical competence.
I recall a lot of renewed energy a year ago into improving OpenSSL, including funding and support. Has that panned out as I would have hoped? LibreSSL improvements are highly visible (and exciting) but I expect I would have overlooked any OpenSSL improvements.
There has been a whole bunch of changes and cleanups in OpenSSL, it's just stuff like that doesn't seem to pick up as much traction here (they don't really have the blogging / communicating thing down so well, I guess?)
This is the current roadmap. https://www.openssl.org/policies/roadmap.html
Picking out a few highlights:
* "Objective met (2015): The FIPS code has been removed from the master branch, and will be re-integrated more cleanly during a future validation. "
* "Objective met (2015): All use of dynamic memory allocation has been cleaned up and made consistent, and the internal memory pool has been removed. "
Under Coding Style:
* "Objective met (2015): All release branches were reformatted using a script included in the release." (so all code now adheres to a consistent style at least, which is a good starting point)
And amongst their targeted goals now:
* Legacy platforms that are unlikely to have wide deployment will be removed from the code.
.. but ..
* Non-supported platforms requiring regular maintenance activities will eventually be removed from the code after first seeking community owners to support the platforms in platform specific repositories.
Not convinced that's necessarily the right route, but I can appreciate where they're coming from.
Yay for EINTR, but you're still handling EAGAIN; it's just called TLS_POLLIN/TLS_POLLOUT now. (Not that this is a bad thing: this is exactly what I'd expect from such an API, as it needs to integrate with the local event loop.)
The "What's wrong with the OpenSSL API" is excellent: a coworker ran into this just recently. A client was failing to connect, and had SSL23_XXX in the stack trace, and he wondered why it was using an outdated version of SSL; since we've long since disabled support for SSLv3 server-side, he figured — reasonably — that the client was failing to connect for that reason.
For those wondering, from the Python docs, which have the best explanation I know of:
> ssl.PROTOCOL_SSLv23
> Selects the highest protocol version that both the client and server support. Despite the name, this option can select “TLS” protocols as well as “SSL”.
I'm just curious and,yes, it's a bit off-topic AND forgetting the relevant dates, etc. that are at play here: isn't developing an SSL/TLS library the sort of thing that Rust should excel at? I see all those lines of C code (and clearly other non-C code) and am thinking of all the opportunities for bugs to come up related to pointer and memory management. Would such a library be a good use of Rust from the performance and safety perspective? Seems like it's how the language is being sold.
Note: I'm not a C developer nor do I typically work at this level of the stack, thus my seeking opinions.
The thing about rewrites is they're great if you're happy to wait three to five years to get back to feature parity with what you have today.
The BSD team needed a library that worked pretty much straight away as a drop in replacement, and then they could gradually bring in a new API on the side. If they had rewritten we'd still be waiting.
Also, the OpenBSD guys are really good at writing C. They have far safer versions of the standard memory and string handling functions, better functions for allocating arrays to guard against integer overflows calculating the size, etc., and the skill and strict standards to use them properly.
But there's a significant difference between auditing, cleaning up, and fixing up an old code base (which, however crappy, contains a lot of domain knowledge and bug fixes that have built up over the years), and a project to write exciting new bugs from scratch, in whatever language.
No, I wouldn't suggest such a thing for the project that is the subject of this story. But in the theoretical sense or if an upstart were to take a "start-from-scratch" approach starting today or maybe some time from now; that's where I'm wondering what those with better insight than I might think.
Alpine Linux still uses OpenSSL since LibreSSL releases is only supported for 1 year while Alpine releases is supported for 2 years. Void Linux has switched to LibreSSL though.
It's not a symlink, but that's a good idea. Eg, openssl has 'nodes' (no DES) which means 'dont encrypt the file you're about to make' and if you omitted it and did encrypt it wouldn't use DES anymore anyway.
Apple for the longest time shipped OpenSSL as a library that developers could link against in their binaries. Unfortunately OpenSSL even in minor versions could and would change function calls thereby making it almost impossible to keep up to date with OpenSSL for dynamic libraries because each new version required the developer to recompile the binary.
Apple thus stopped shipping OpenSSL and has officially deprecated it, these days you won't find headers for it anywhere in the stock system and there is no official way to link against it anymore either in El Capitan. It just exists for backwards compatibility.
If a developer now wants to use OpenSSL in their binary instead of the Common Crypto framework that Apple provides they will have to provide their own version of the library in their application, and they are then responsible for making sure users get patched in time.
Thanks. It looks like they're still shipping it (eg, it's in /usr/bin on El Capitan which is otherwise protected) but they're not shipping headers. Do you have a link for them deprecating it?
Yep, they are still shipping the binary, mostly for compatibility for scripts that require it. I have a feeling even that binary is eventually going to get dropped.
I'm not sure that Apple promised to stay with OpenSSL. Apple developed CryptoCommons wrapper for some OpenSSL methods and I'm sure, that they can make it work with LibreSSL. I was under impression that it was made specifically to be able to drop OpenSSL when they would want it.
Those are the newer libraries you're _suppose_ to use, rather than OpenSSL. It's mostly older applications and codebases that limit Apple. I could imagine a stop-point but Apple obsesses a lot about not breaking backwards compatibility.
Don't forget their version is ancient (API-wise; they back-port fixes) and LibreSSL is much newer, so it's not a drop in replacement for such an old version.
For example, I find worthless the Annex K of C11 as solution for memory corruption, because the functions still require to keep track of a separate pointer and size, while making sure they match. And the Annex is anyway optional.
However OpenBSD coding guidelines do look quite good:
Yes. The literally reason LibreSSL uses ComicSans is to troll the "HN Crowd" according to their early homepage. It started as, "help us reach this donation goal to remove comicsans".
By this point its just to troll people. Since using comic sans will trigger at least 1 discussion about the font itself. This is actually a good filter community wise. If you won't suffer certain fonts your certainly not gonna stomach hand reading OpenSSL code to figure out its indented goal.
They probably do it deliberately. It's an excellent filter for people who are bikeshedding, vs people who have something to say about the actual content.
It says there's more people who can comment on font choices than on SSL internals (I'm one of those people, btw - no shame in not knowing advanced crypto). I'm pretty sure this is the same lesson you draw from the original "bikeshed" story, so it's doing its job pretty well.
No matter how you feel about the forking or the openbsd team, there is something to be learned here. There are times when forking, deleting old code, and major clean-ups can be very useful strategies. Sunk cost bias can be an enemy of progress.
[1] - https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...