Theo de Raadt on OpenSSL vulnerabilities coming on the 19th

Wouldn't that be "they embargo reported bugs and we don't"? (Or at least, I suspect LibreSSL wants to keep to its own embargo schedule.)

Not true.

> I bet if the embargo were for 5 days they would reconsider.

Here's a page describing the list in question:

http://oss-security.openwall.org/wiki/mailing-lists/distros

Here's the embargo policy:

> Please note that the maximum acceptable embargo period for issues disclosed to these lists is 14 to 19 days .... In fact, embargo periods shorter than 7 days are preferable.

So what about having the dinosaurs sort out and coordinate release dates initially, then giving a few days heads up to LibreSSL (and others).

At least it would minimize the risk of zero-daying LibreSSL users.

... but I guess, this isn't where the problem is?

It's not "in the wild."

OpenBSD is making the gamble that either a) they can pressure the adults doing coordinated disclosure to stop doing that via their excellent people skills, or b) that they are so awesome that they can find the problems before everyone else.

NB: I love OpenBSD from a security POV, but that doesn't mean what the leaders of the project do is always correct for security.

> OpenSSL served the entire internet for years.

Well, it gave the entire Internet a false sense of security for years, at least.

> …the hate just seems petty.

Have you read some of the cruft that the LibreSSL guys removed? OpenSSL has been a horrid mess. Sometimes you gotta admit that a Yugo is a really, really, really bad car.

What's petty about removing bad code? If someone came into your (work or FOSS) project and just started removing code at the clip they were, you'd probably be extremely upset. At best, it would take way too long to get the approvals by the community. They made the decision that with the changes they wanted (and in their opinion needed) to make would not be worth the politics involved. I don't blame them for that decision. As a byproduct, they are now maintainers of their own system, and as shown by OpenSSH, they are very good stewards of critical systems. Then they ported it back to Linux, and got a call added to the kernel. I wouldn't call that petty.

I think it would have been better had OpenSSL just been straight up fixed rather than forked, but can you legitimately see a way for that to have happened?

To my knowledge, the OpenBSD guys have not hated on the OpenSSL guys in any way, they have hated on the code itself, which was objectively bad code with many latent bugs. Any comments about not knowing how to write secure code resulted from what was produced: insecure code.

Scorching the earth is the right thing to do. OpenSSL is the sick man of the internet and its community has been dysfunctional to non-functional for years, much like its code. The massive injection of money won't solve that problem in the long term. The security patches ought to be integrated with LibreSSL immediately, not after an embargo period dictated by the vendors who have essentially bought out OpenSSL.

It would be nice if he'd said that, rather than "Well, they just don't." which completely misrepresents the situation. AFAIK, he has never requested such a thing, anyway. The only requests I see come from third party apologists, not from him.

He just complains that they don't give him access, when in fact they offered him access.

> Theo meant he has no time to join yet another mailing list where OpenSSL security issues are very likely way less an 1% of the messages.

Is it really that hard to filter for /openssl/i/?

I must be missing something, because I don't understand what's so difficult about filtering out the irrelevant emails.

To me it seems mostly a difference in principles. If OpenSSL and others work with embargoes and LibreSSL/OpenBSD doesn't accept them, there is no solution that satisfies both sides.

The amount of mails sounds like a strange argument to me. I can't imagine that they couldn't find one of the regular consumers of the mailing list willing to pass relevant ones on, assuming it were clear that LibreSSL is an accepted recipient of the information.

That said, I don't expect much in the way of goodwill or willingness to compromise on any side here.

> Also, it's a Linux mailing list and he maintains a BSD distro, not much in common.

No, you're thinking of linux-distros@. linux-distros@ is where issues that affect Linux only go. distros@ covers issues that are relevant to both BSD and Linux - distros@ membership is FreeBSD+NetBSD+linux-distros@.

The distros list works on the principle that, at least in part, it's about people who are participating in the security-fix process. Of course some of the benefit is you get to stage your fixes early, but you also agree to be another set of eyes on the patch, run your local build and regression tests, etc. If someone brings an issue to the distros list without a patch, the patch needs to get written by someone. And so forth.

My employer repackages Ubuntu into a virtual appliance, but since we're firmly downstream and haven't yet had the time to get deeply involved in upstream security work, we're not allowed on the distros list. (We haven't asked, but the policy is pretty clear.) I think that's pretty fair, even if I personally dislike that end result.

See for instance, the disastrous handling around Shellshock, where no details were given on the distros list, the announcement went public, and it took a few days (in public) for people, mostly people on distros@, to realize that the patch was incomplete and two more patches were needed. It's not clear the distros list worked any better than a public announcement would have.

The other argument is that embargoes always get harder to enforce as you add more people to them. The distros list is the successor of the old vendor-sec list, which was more lenient about membership and always had suspicions of leaks (until someone broke into the mail server....). See, for instance, the messy handling of Heartbleed's embargo:

http://www.theage.com.au/it-pro/security-it/heartbleed-discl...

I think that if there's going to be a private disclosure process at all, it's better that it's bureaucratic instead of friends telling their friends at CloudFlare and Akamai, under the table, that they should patch.