OpenSSL Forked By OpenBSD Into LibreSSL

[wretched_dutchman]

For all you people who are crying out about why it was forked and they shouldn't have etc. Here's the memoires of one of the masterminds behind it all:
http://www.tedunangst.com/flak/post/origins-of-libressl

[OneTimeShot]

Hmm.. OpenBSD ripping on other projects?

I don't think that it is on for OpenBSD people to start berating OpenSSL as a group. It's not like OpenBSD has never, ever, ever, had a bug or security problem (and Heart Bleed is "just" information leakage - we're not even talking a remote root exploit here).

What Heart Bleed shows is how prevalent OpenSSL is as a piece of software - and how bad we are at patching all that software when bugs are found. Further it shows that even a piece of software as eyeballed as much as OpenSSL is, can have a "simple" (when someone else points it out) bug missed for a couple of years.

Sure, everyone thinks that they can rewrite from scratch and create the most perfect piece of code ever. The reality is that they can't, and they'll get it wrong occasionally too. So the question is not "how do I write software with no bugs?", but "given the inevitability that there will be bugs - how do we best find them, and how do we get the fixes out?"

[Spittie]

Really !?!? cowards !!! instead of helping the project they fork it so they wont be harmed ?? the nerve ...

Do you think the changes they've introduced would have merged upstream?
They pretty much changes the whole indent style (from Whitesmiths to KNF), removed support for several architectures (less common and more common, like Windows), removed support for pretty much every hardware backend, removed lots of custom functions instead of using the system ones, and a lot more (see https://lobste.rs/s/3utipo/openbsd_h...omments/fkwgqw and http://opensslrampage.org/). It's not just bug fixes (those are shared with OpenSSL, I hope).
They want to get it down to a minimal code base (iirc it's down to ~150k lines from ~300k already) so that later they can audit it.

I, for one, hope that LibreSSL will get mainstream utilization even outside OpenBSD.

[soupbowl]

This is a good move.

[GreatEmerald]

They have to unless they rewrite everything.

They cannot change the license of existing code.
I had a similar interest in the license they plan to use and quickly looked at OpenSSH for comparison:
The original license is kept in existing files but new files use the 2-clause BSD license.

I thought it was obvious from the context, but I guess I should have stated that I meant new code, not existing one.

It's not like GnuTLS had a critical bug discovered two months ago... ( http://www.gnutls.org/security.html )
GnuTLS does not have a reputation of following high coding standards, so I'm not sure I would advise using GnuTLS over OpenSSL.

No software is perfect, but at least GnuTLS has a sane license and no forks. Not yet, anyway. And it uses nettle/libgcrypt, which sounds like a good part of what LibreSSL is trying to create out of OpenSSL now.

[Serge]

Although I'm not qualified to investigate this decision on my own, according to the rhetoric presented so far it appears to me that this fork was a good move by the OpenBSD developers. So far from what I've gathered, de Raadt et al.'s concerns with OpenSSL have been two-fold. First, there is a lot of poorly functioning features, poor documentation, and legacy cruft that gets in the way of useful development. Second, the OpenSSL development is not conducted in what OpenBSD devs consider to be a responsible or accountable manner. The first set of concerns can be addressed within the framework of the existing OpenSSL project, although legacy stakeholders may attempt to obstruct some of the efforts at code clean-up. However, such effort would be mis-spent if the root situation that caused these problems with the code and documentation is not addressed. Hence, if we are to accept the OpenBSD devs' criticisms of OpenSSL as true, then it only stands to reason that code clean-up and future development should be done in a fork, not within the original confines.

Granted, what OpenBSD devs describe as responsible and accountable development practices are might be considered too strict and demanding for many types of projects. However, given the wide usage and grave security importance of SSL, I think the OpenBSD way is exactly what is needed for this particular type of project.

Much of the rhetoric employed by X / Wayland devs in explaining why Wayland was necessary included complaints about legacy cruft, poorly documented and poorly understood functionality, and obstructionist legacy stakeholders. Wayland was able to abandon X but keep X.Org Foundation. I am not sure why LibreSSL had to leave the OpenSSL administrative structure behind - perhaps they felt that the administrative structure was partially to blame for the development model, or perhaps they favor their own administrative structure out of some sense of NIH. Regardless, I don't think that's important. I think the administrative / financial / legal stuff is boring and ought to be commodotized anyway.

[ua=42]

Summery of LibreSSL:
* Pare down the code to just the essential bits.
** Git rid of reimplementation of standard calls like malloc, printf, etc, and instead use the system's versions.
* Use safer, more secure functions. Ex: they are replacing malloc with calloc. Calloc on most systems checks to see if memory is out of bounds automatically.
* Document and make the code easy to read and understand.
Then:
* Audit the code.
* Port the code in a sane manner to other systems.

[Szzz]

OpenSSL is written by monkeys (article from 2009): https://www.peereboom.us/assl/assl/html/openssl.html

[old486whizz]

Summery of LibreSSL:
* Pare down the code to just the essential bits.
** Git rid of reimplementation of standard calls like malloc, printf, etc, and instead use the system's versions.
* Use safer, more secure functions. Ex: they are replacing malloc with calloc. Calloc on most systems checks to see if memory is out of bounds automatically.
* Document and make the code easy to read and understand.
Then:
* Audit the code.
* Port the code in a sane manner to other systems.

Oh yeah, let's get rid of a source of entropy by using calloc / malloc provided by the kernel.. Meaning that any data there gets wiped clean.
I'll tell you what, why not do what the Debian devs did not too long ago and stop the code from getting any entropy and limiting the cryptography to a limited subset? oh wait - they seem to be involved with this fork along with the BSD guys!

(Open)BSD has never been concerned with porting code to other systems - they code for themselves and that's that. Any other "portability" code is kept outside and managed outside by specific devs.

I am surprised that openSSL is all-encompassing and think it should have been split apart (network protocol section vs encryption/crypto section). That way none of this would be much of an issue (network part doesn't and shouldn't have same memory requirements as crypto etc).
There's also the issue of government certifications where openSSL has had to be able to check it's own memory usage etc to certify it is clean and untampered. Can't remember the certification OTOH but I looked into it 2-3 years ago.

[curaga]

I approve of this. Especially the removal of support for the rarely-used platform Windows.

But for the name I expected OpenOpenSSL.