LibreSSL 2.1.5 released | Hacker News Reader

LibreSSL 2.1.5 released

marc.info

96 pointsfcambus34 comments

The LibreSSL version scheme corresponds to OpenBSD version numbers:

2.0.x -> OpenBSD 5.6, 2.1.x -> OpenBSD 5.7, 2.2.x -> OpenBSD 5.8,

Development slowed approaching the end of 2.1.x as the OpenBSD tree went in release mode lockdown. It is interesting to see the development coordination that stops and restarts the tree activity.

Things in the pipeline for 2.2.x include AIX, Cygwin, Visual Studio support, and wider support for optimizations (currently only ELF/OS X x64 is supported). In general, expect libtls to expand in features and improve usability, more code to be pruned and simplified.

There were not many SSL patches for OpenBSD 5.6, and there were not any LibreSSL 2.0.x releases after 2.1.x began. However, we are looking at possibly releasing further 2.1.x updates if there is interest. They would correspond to OpenBSD 5.7 errata.

If the LibreSSL corresponds to OpenBSD version numbers then it should be numbered 2.5.6 => 2.5.7 => 2.5.8 etc.

We wanted to also push out releases faster than OpenBSD's 6 month cycle. Maybe we should have started at 5.6.0. I dunno, hindsight is 20/20.

From the release announcement :

This or earlier LibreSSL releases may also address issues that are to be revealed by The OpenSSL Project Team on the 19th of March, 2015.

That sounds a bit passive-aggressive, no?

Passive-aggressive from whom? OpenSSL who don't tell LibreSSL about security flaws, or LibreSSL who need to wait for OpenSSL to do a release before they can find out about security vulnerabilities?

Why should OpenSSL tell anything to LibreSSL? LibreSSL had very negative words for OpenSSL in the past and tried to build the impression of being "more secure" just based on the "low hanging fruits." It's easy to make the fork and reformat or remove the parts of the code. It's much harder to find the real security problems in what remains.

If I were in OpenSSL team I would also not tell LibreSSL anything and then in, for example, a year show statistics how often LibreSSL wasn't "more secure" at all. That's a fair comparison. (1)

Hard problems are hard.

1) Edit: but see fafner's comment here, it seems the truth is even harder to believe: it seems it's the LibreSSL guys themselves who decided not to be informed and now write what they write(!)

Now that is not a very engineering-wise useful behavior. You may feel bad (I mean OpenSSL not "you") but do you want a better Internet or not?

It is as easy as an encrypted email.

Put yourself in OpenSSL shoes. Would you then really send your still confidential bugs to the people who claimed you're incompetent but they themselves didn't remove the said bugs after promoting their work and speaking bad about you for months?

Even if you would, can you know if they would not leak them before your correspondents (which include really big companies which can really be in danger if the leak occurs) are ready? (See fafner's comment here for some details -- apparently LibreSSL people didn't want to guarantee not to leak(!)) You just know they are antagonistic to you.

No, they have different goals and different standards. I think people are attributing "antagonistic" when it really isn't there or is not nearly at the level the general geekdom thinks it is. Theo doesn't believe in embargoes. Theo doesn't want to be a part of yet another list when he is already swamped with the task load he has. I see zero problem with that. That the OpenSSL and LibreSSL teams talk is readily apparent though.

Please read the commit log of LibreSSL and try not to face-palm. I think you will fail. The code quality they're up against is very often stuff you expect to find at thedailywtf.com. It must always be ok to criticize (even in the form of mocking) bad code as long as the criticism comes with well written patches. OpenSSL should embrace the help they get for the greater good.

If the mocking is the fair game, everybody can mock LibreSSL too for not actually finding the real security bugs that exist in their code after more months of publicly claiming they are "more secure." I admit they had a few ideas OK, but for my taste they made too much self-promotion and "mocking" of the original developers. I allow you the right to like that, I just state that I don't and stand behind it.

See also fafner's comment here and think about it.

OpenSSL is free to do that, but given the issues in their code it would probably backfire.

Or instead of just forking OpenSSL then should help develop/submit patches to OpenSSL and improve the existing code base.

And they could have found the security bugs and report them to OpenSSL even after they forked. If they actually did some serious security investigations of the code they took and kept in their fork, it should be natural to discover such issues and not just wait for others to find them in OpenSSL.

Does anybody know of any such report?

While I generally agree that this should be done, I'd also like to point out that many (most?) security fixes in LibreSSL are really "side effects" from trowing away lots of code, or cleaning it up.

That's my impression too, that they threw away a lot and replaced a few functions with the "good-practice in OpenSSL" ones, but otherwise haven't changed too much, so the code base can be easier to maintain but is not necessary "the" solution some believe it is.

> Or instead of just forking OpenSSL then should help develop/submit patches to OpenSSL and improve the existing code base.

Part of the early LibreSSL work was auditing and merging security patches which had been in the OpenSSL tracker for months or years.

Do LibreSSL and OpenSSL have the same goals? Do they both want to support the same features/hardware/etc.? If LibreSSL remove something because it's not needed for what LibreSSL wants to support, but OpenSSL does want to support it, then what should happen? Should it be removed? Or not?

Different projects can have different goals.

A good portion of LibreSSL's patches are in the form of removing code for dead platforms like VAX/VMS and OS/2, problematic wrappers like openssl_malloc() or patching the everything-on-by-default approach that OpenSSL takes. The OpenSSL team actively refuses any such patches, which is why LibreSSL was forked in the first place.

Isn't that largely because the LibreSSL team refused the invite to the exclusive OpenSSL security list? At least that was the case the last time the LibreSSL devs complained about not receiving any vuln info in advance...

> Isn't that largely because the LibreSSL team refused the invite to the exclusive OpenSSL security list?

Would you have a source for that? And for their reasoning behind it? Was "last time" poodle or something else?

edit: in the sister thread[0] rlpb suggests the point of contention is that OpenSSL embargoes but Theo/OpenBSD (and thus libressl) does not take part in embargoes (and other issues including Theo being Theo), linking to http://lwn.net/Articles/601958/ as supporting evidence, which looks to cover just about all grounds.

[0] https://news.ycombinator.com/item?id=9217022

> Was "last time" poodle or something else?

Excuse me please, I see you are emotional about the issue but I don't think it's the good way to discuss it. Asking for the source for the claim is OK, this however...

> Excuse me please, I see you are emotional about the issue […] Asking for the source for the claim is OK, this however...

Uh what? I was just providing a relatively recent issue which IIRC libressl was also affected by as a possible candidate (turns out the issue in question is much older and not a "named vulnerability")

Story, with sources, at: http://lwn.net/Articles/601958/

They were asked to join the distros list, and they declined.

Yep, found it just a few minutes ago and added it as an edit to the original comment. Thanks a lot.

> the LibreSSL team refused the invite to the exclusive OpenSSL security list

As I understand it, they refused to accept embargoes (or guarantee that they wouldn't just go and scream "FIRE!" if one broke out, even before they could put it out) -- or patch ahead of other's etc.

The "responsible" vs "full" disclosure thing. There are arguments on both sides, but from the perspective of being a developer, I can understand the whish to just be able to say: "Oh, shit. Turn off your SSL services now, this and this has been seen in the wild. We're working on a fix" -- rather than let some small number of juicy targets be compromised because someone had an exploit, but hardly anyone knew about it.

At any rate, if one was happy with openssl, one can just stick to openssl. Probably a pretty bad idea, though.

http://marc.info/?l=openbsd-misc&m=140200815827477&w=2

    Another way to phrase this is

        The OpenBSD user community should accept they have suffered
        because Theo declined an invitation to a private email list,
        entirely unrelated to the vendor who was in control of deciding
        where the notification would go.

If you read the actual email thread http://marc.info/?t=140199386400003&r=3&w=2 you'll get a different perspective than the one that comes from a game of telephone played with social media comments.

This comment is why we need a "DERAIL" button here. To split it into a different area.

The comment is perhaps valid, but deflects from the discussion. Yet here it is sitting at the top of the comments page. Not ideal.

"Take it to Tangency" was the old phrase on rpg.net

It's quite PA when you know what the Friday disclosure is about and can see the LibreSSL hasn't (accidentally) fixed it.

Given that OpenSSL tried to get LibreSSL on the embargo list and the LibreSSL team declined due to their stance on embargoes, it seems uneventful to find out that they didn't did early access to this embargoed information.

The question of whether LibreSSL has fixes for OpenSSL issues comes up frequently enough that it made sense to note it directly.

Fixes and improvements have certainly been shared between the Boring, Open and LibreSSL teams, and we look forward to further cooperation. It is obviously beneficial.

LibreSSL has in the past mitigated issues that later became known in OpenSSL through security updates. Sometimes, it has been still vulnerable to OpenSSL issues as well. Hopefully we'll fall into the former camp this time around.

To the security researchers and developers who have reached out, we are very grateful.

Nice to see some work being done on the Windows port!

Reply on news.ycombinator.com