I think you've been cut out of enough embargoes to understand the openbsd position. Embargoes hurt users.
I disagree. Embargoes are good for users, as long as (a) people actually respect the embargoes (rather than leaking details, whether to Theo or on a public Linux kernel mailing list), (b) the right people are part of the embargo, and (c) the embargo is not unreasonable long (Intel in particular fails here).
The decision to not work together on lazy FPU was made before Theo got involved.
Leaving aside the question of who refused to sign an NDA, after details were leaked to Theo he made a decision to go public rather than attempting to work productively with other vendors.
What Theo and others, including myself, have made clear is that embargoes suck, and we will complain about them as is our right, but we will attempt to honor them if that's how it going to be.
You can complain all you want, but if you want other people to give you advance notice of vulnerabilities they find, you should be prepared to give people advance notice of vulnerabilities you find. As long as OpenBSD has a policy of "bugs we find get fixed immediately, without talking to other vendors" you're going to run into problems here.
Which is why I love OpenBSD. You're literally complaining that OpenBSD closes security holes too quickly! As a user I want that.
We need to be honest that embargoes serve a couple different purposes. One might be to prevent the leaking of information to malicious actors, and another is to protect vendors and HW manufacturers from embarrassment. As a user I don't care about the latter. Also, as someone concerned with the state of the world I dislike secret clubs, and I fear the reliance on secret clubs provides a false sense of secretivenss. Secrets leak.
If the bug is important enough to warrant an embargo it needs to be fixed ASAP. A month is too long to run with an important vuln in running code. It's always going to be a balance, and as a user not involved in any secret security clubs I want those bugs fixed and in the public space as quickly as reasonably possible.
On the other hand, by publishing the vulnerability, you’re making people running all those other systems more vulnerable. The point of the embargo process is collective security, rather than just the security of your own users. One day, your project of choice won’t be able to fix a vulnerability as quickly as another - and you’ll be left in the lurch then, without an embargo.
Balls were definitely dropped. My understanding of the Lazy FPU event is that (a) someone at Intel asked if OpenBSD signed NDAs and was told no, then shrugged their shoulders and didn't pursue it any further; and (b) someone at OpenBSD tried to get in touch with Intel, but didn't talk to the right people (Intel is very siloed), and didn't get anywhere.
I've witnessed conversations since then between Intel people and FreeBSD people basically consisting of FreeBSD people saying "you guys really need to include OpenBSD" and Intel people saying "yeah... can you help get us connected with the right people?" so I don't think it's fair to suggest that OpenBSD is being purposely excluded.
Is OpenBSD supposed to comply with secret terms
I think that OpenBSD should follow the norms of the security community, i.e., contacting other operating system vendors and coordinating disclosures -- regardless of how they come across a vulnerability.
So that one day they might get invited to the cool kids secret club?
Not breaking embargoes doesn't seem to have done that for them yet.
Instead we get people like you FUDing about how they are unable to keep secrets and are justifiably being blocked from information.
I'd rather they look out for me, a user, than get the worst of both worlds, just because one day it might pay off.
these kind of memes last literally forever, in 10 years they will still be talking about how OpenBSD "broke" the KRACK embargo, and we shouldn't tell them anything.
> Is OpenBSD supposed to comply with secret terms that they are purposely not made aware of, nor have agreed to?
You discovered the secret, but recognize that embargoes still have value even if you weren't part of it. Be the better project, show magnanimity, and don't place end users of other projects at undue risk.
> That's a pretty unfair standard don't you think?
I agree that 12 month embargoes are stupid. I know that there are people, including FreeBSD people, who have been vigorously encouraging Intel to be more reasonable about how such issues are handled.
I played a small role in that after Theo announced the Lazy FPU issue, by writing exploit code and telling Intel (via the FreeBSD people in the embargo) "shorten the embargo or else".
Given how much Intel likes to throw their weight around wrt embargo terms well past the point of being unreasonable, maybe it's a good thing that someone holds a gun to their head every once in a while.
If you want to lead market in mission-critical product, there's a certain amount of responsibility that you have to your customers and more than once Intel has lost sight of that.
I disagree. Embargoes are good for users, as long as (a) people actually respect the embargoes (rather than leaking details, whether to Theo or on a public Linux kernel mailing list), (b) the right people are part of the embargo, and (c) the embargo is not unreasonable long (Intel in particular fails here).
The decision to not work together on lazy FPU was made before Theo got involved.
Leaving aside the question of who refused to sign an NDA, after details were leaked to Theo he made a decision to go public rather than attempting to work productively with other vendors.
What Theo and others, including myself, have made clear is that embargoes suck, and we will complain about them as is our right, but we will attempt to honor them if that's how it going to be.
You can complain all you want, but if you want other people to give you advance notice of vulnerabilities they find, you should be prepared to give people advance notice of vulnerabilities you find. As long as OpenBSD has a policy of "bugs we find get fixed immediately, without talking to other vendors" you're going to run into problems here.