Hacker News Reader

Comment by technofiend | Hacker News Reader

Surprised no one has yet mentioned LibreSSL, OpenBSD's fork which happened after the last major bug. http://www.libressl.org/

View on HN

Is there any coordination between OpenBSD and the Linux Foundation? For example, did the Linux Foundation consider adopting OpenBSD's fork rather than auditing and fixing the original?

EDIT: What is the status of LibreSSL?

Auditing and fixing the original still improves LibreSSL, although one of the main goals of LibreSSL was to clean things up to make that easier.

Last LibreSSL release was 2.1.4 last week, although a minor update should be coming soon. http://marc.info/?l=openbsd-announce&m=142543818707898&w=2

LibreSSL is going to track OpenBSD versions, so now that OpenBSD 5.7 is done, the LibreSSL 2.1.x series is done (except to receive patches). At some point a 2.2 release will be made, corresponding to new developments.

Thanks. Did OpenBSD get the funding they sought for LibreSSL? How mature is it at this point? I see it's included (?) with OpenBSD, which is a good sign.

libressl's binary is already half the size of openssl. I wonder if the audit is re-doing existing work to some extent.

> libressl's binary is already half the size of openssl

What does binary size have to do with quality?

OpenSSL has been around for a long time, and still is the standard for most deployments. It will take a long time before LibreSSL has been proven enough to become the standard for anything outside the BSD community.

For as nasty as the OpenSSL code appears to be, it sure did work (and worked well) for a long time.

Remember, OpenSSL really only had 1 developer and only received around $2,000 a year in donations prior to Heartbleed[1] (which is grossly pathetic for such a critical piece of software).

If those numbers had been tenfold or more, perhaps the bugs that led to Heartbleed may have been found and fixed long before they were an issue.

Thankfully the Linux Foundation and the Core Infrastructure Initiative are aiming to remedy this.

[1] http://arstechnica.com/information-technology/2014/04/tech-g...

> What does binary size have to do with quality?

I think grandparent meant that binary size is related to code size. The number of bugs being related to the number of lines of code, you could infer that a bigger binary means more lines of code which means more bugs. In my experience, this tends to be true. Of course this makes the big assumption that the binaries have been compiled with similar compilers using similar optimizations and are both stripped.

> What does binary size have to do with quality?

Do OS/2, 16 bit Windows, and Data General Unix support indicate quality to you?

http://opensslrampage.org/

It doesn't indicate either way. If the code is in there, if it works for those platforms, and has no adverse effects on other portions of the codebase, then it doesn't matter (those code paths are never executed unless you run on those platforms).

You can't guarantee that code path never gets executed. For a good historical example, Windows NT4 also came with inbuilt OS/2 and POSIX subsystems that were never used by users, but typically used by people on the internet to crack boxes.

While I haven't look at the OS/2 support of OpensSSL specifically, surely it is not a question about code that it never executed, but code that is never built on a modern system. That makes it more a question about code maintainability and code readability, rather than security problems with seldom executed code.

Much of the code you don't think was ever built on a modern system was being built. Either because they enabled the workaround everywhere on purpose, or because the preprocessor test was borked and the modern code never enabled.

That's likely true in the case of OS/2, DGUX workarounds might be ran on Unix boxes.

It's all dead code that any of us here would remove from our own software projects - and your point about the OpenSSL team's lack of resources is quite relevant to that.

I have to say, LibreSSL's snarky PR stance when it was first launched really turned me off. This stuff is hard and the code is old; being an asshole about the code quality is really inappropriate. Has their behavior matured since then?

No reason you can't look at the recent commits yourself and determine if they are 'mature' enough for you.

They did really try to seize the moment and imho did act a bit disingenuous towards OpenSSL. They even played on the point that OpenSSL's coding style wasn't "modern" and adequate and therefore made it near impossible for people to work on[1]. Since when does having curly brackets on different lines make something impossible to read?

They also gutted more than 90,000 lines in the first month (something that would be naive to claim had absolutely no unintended side effects), and claimed the OpenSSL project would not accept a single change (sort of alluding to the OpenSSL project having some delusional desire to stay "broken"), mandating the fork[1][2].

OpenSSL was largely written by cryptographers. LibreSSL is being hacked on by OpenBSD developers.

OpenSSL's code may not be pretty, but I sure think it would have been a better use of time and efforts to have the OpenBSD developers work alongside the OpenSSL cryptographers.

[1] http://www.infoq.com/news/2014/05/libre-ssl-first-30-days

[2] http://arstechnica.com/information-technology/2014/04/openss...

They did, but they also were frustrated beyond sanity at what OpenSSL was doing like adding a wrapper around malloc & free and that was new code not old legacy cruft that can be excused. It also taught us all an important lesson in rage commits when Theo screwed up one of them :-P

OpenSSL development far exceeds LibreSSL, I believe they should fix OpenSSL instead of trying to fork it.

OpenSSL: http://git.openssl.org/gitweb/?p=openssl.git;a=shortlog vs LibreSSL: https://github.com/libressl-portable/portable/commits/master

Seems LibreSSL is a mainly a one-man band?

You are looking at the wrong repository -- that is a portable version of libressl (I agree it's non-obvious how to find the true repository, as it is stored in CVS).

This is closer, and a bit busier: https://github.com/libressl-portable/openbsd

I stand corrected regarding the libressl repo, Regarding active development, it still doesn't look that busy.

Sure more people committing but several days with no changes, vs the commit changes on OpenSSL.

OpenBSD is about to tag 5.7 for release. During the release window commits normally drop to only include minor changes. Once the tree is tagged all the patches sitting in the developers private trees can go in.

Regarding libressl I'm not sure how it works, but I think the OpenBSD cvs server is a better source that the github repo (http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/), but I'm not sure.

Also I'm not sure that a rapid flow of commits are necessarily a good indicator of quality.

Reply on news.ycombinator.com