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.
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.
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.
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(!)
It is as easy as an encrypted email.
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.
See also fafner's comment here and think about it.
Does anybody know of any such report?
Part of the early LibreSSL work was auditing and merging security patches which had been in the OpenSSL tracker for months or years.
Different projects can have different goals.
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.
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...
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")
They were asked to join the distros list, and they declined.
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.
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.
The comment is perhaps valid, but deflects from the discussion. Yet here it is sitting at the top of the comments page. Not ideal.