Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

OpenBSD has a reputation for not respecting embargoes, even as recently as the KRACK wifi thing last year.

If you have a history of breaking embargoes, you're going to stop getting included in them.

Edit: Changed to reflect the explicit nature, as it seems the answer is not all BSDs ;)



Please stop defending (if implicitly) Intel's irresponsible disclosure. We at Joyent are (1) a public cloud, (2) have our own operating system (SmartOS), (3) have always respected embargoes and (4) have a close relationship with Intel (!!) -- and we weren't notified either. OpenBSD was not excluded -- rather they (and we and every other system that isn't Windows, MacOS and Linux) were not included. What Intel did here was hugely irresponsible, leaving many in a vulnerable position for an extended period of time; there is nothing that OpenBSD (or anyone else) did to deserve such shabby treatment.


They dropped the ball all around.

Even with 6 months lead time, they were startlingly unprepared in all but their works-as-designed press release.


I think HN user pinewurst nailed it back in 2016: "[Intel] are basically a PR firm with a good fab in the basement".

https://news.ycombinator.com/item?id=11820078

Their handling of recent events has really cemented this view in my mind.


Paraphrasing Linus, "talk is cheap, show me the silicon"

While it's fair to criticize them, sometimes it comes across as "those hardware bozos don't know what they're doing" and hardware design, at the speeds and features Intel does is hard (just look at the number of competitors)


I think that was a typo, though, and he meant to refer to IBM.

You have to remember that IBM's PR is stuff like "Watson is sitting here curing cancer right now while his best friend Deep Blue beats people at chess!!11!" Intel doesn't do any of that.


No, it really was in reference to Intel (the thread was about Intel obtaining and developing a dinosaur-era distributed file system called Lustre).


Lustre may be old, but it's hardly useless. Some of its capabilities cannot be replaced by any modern storage systems object and file alike.

CEPH comes close, but cannot completely replace it.

When you connect a thousand nodes to a single storage pool with high throughput and low latency requirements, not everything can cut it.


and that was sadly the right thing to do. why? because they will have zero consequences. not even the inside (pun intended) trading thing will stick.


Well In a perfect world, a lot of these users will revolt and at least buy more AMD EPIC, which is very price competitive. But Intel is going to do what they do best, give you lots of discount in upcoming chips order to keep you happy. And in Business it is really hard to say no to that.

Then there are other segments including Gamers and Casual users, who really believe in Intel's brand and could careless about what Intel did.

Basically we dont see any damages being done to Intel. And when their PR spin how good their 10nm is and Intel being the underdog with Qualcomm in Modem race, everyone would have forgotten about Meltdown and Spectre.


This is fair. If it wasn't a matter of conscious exclusion based on past actions, then I would agree it's poorly handled, and for FreeBSD, Illumos, et al., I can't disagree with you.


This defense of intel is made even more ridiculous by the fact that they chose to exclude the BSDs before the KRACK controversy happened.


Not defending Intel, just trying to understand their position other than just being negligent. Wouldn't it undermine most users if the security flaw had leaked before major OS fixed it? The more you share, the easier it is for a leak to happen. So they could have decided to share only with the major OS first and then later, once fixes have been implemented, expand this to other interested parties?


The BSDs have a reputation for not respecting embargoes

I can't speak for other BSDs, but I'm not aware of any time in the past 15 years when FreeBSD has failed to respect an embargo.


Thanks. I've updated my post to reflect this


Now I don't have all the information at my fingertips but IIRC with KRACK it was OpenBSD (not all the BSDs) that commited the fix early and they _did_ have permission to do this but the security researcher did regret giving this to them.

I think (but not really sure someone please correct me) that openbsd has a policy of not signing NDAs but I think freebsd devs are willing. Why they, netbs, or illumos (although I have no information on how they handle these kinds of disclosures) wasn't alerted is beyond me.


I've heard other variations of this story that stated that OpenBSD simply had the fix ready first, asked permission to commit it (without fanfare), and got it. As far as I remember from the discoverer's CCC talk, OpenBSD got the fix first because he discovered the vulnerability first in OpenBSD's WPA implementation.

It's not that OpenBSD did not want to cooperate, it's that there was some miscommunication that ended up not fitting in the coordinated disclosure.


>I've heard other variations of this story that stated that OpenBSD simply had the fix ready first

Why dont you reach to the source?

>Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability.

https://www.krackattacks.com/#openbsd


> OpenBSD has a reputation for not respecting embargoes, even as recently as the KRACK wifi thing last year.

Stop spreading this FUD. OpenBSD developers were allowed to make the patch silently, they contacted the KRACK researcher and he agreed to this. HE CHANGED HIS MIND LATER, after the patch went it and he started blaming OBSD and spreading bullshit.

>Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability.

https://www.krackattacks.com/#openbsd


There's a whole other thread covering this.

He asked them to respect the extension. They pushed back against it. Rather than making a big fight about it, he shrugged and went "Well, fine, whatever"

It was obviously not an amenable thing to him, because he's specifically not even going to give them the same level of warning with the understanding they must respect the full embargo period, because right after the bit you quoted, he says:

>To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.

If it was just him going "Yeah dudes go for it it's cool everyone else will have to wait out the extended embargo but you can just release the patch immediately!" he wouldn't be punishing OpenBSD for it.


You know, it's really tiring that people keep up with the same old shtick every time the topic of embargoes and OpenBSD come up.

OpenBSD followed [0] the original embargo from the KRACK researcher, he gave OpenBSD the go-ahead to commit it.. only later we he got CERT involved did they want to delay it for more months. He changed his mind retroactively. It's even stated in the original FAQ for that particular security issue.

Enough already? This has nothing to do with Intel's very selective disclosure of Meltdown.

[0] https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbh...


OpenBSD followed the original embargo, and got asked to extend it based on the CERT response. You guys said no, and the security researcher shrugged and went 'Well, okay, I guess.' When everyone else is agreeing to the extended embargo, I personally can't say that I feel like OpenBSD respected the embargo there.

It's also not limited to just KRACK. With the OpenSSL/LibreSSL stuff back in 2015, OpenBSD wasn't part of the disclosure because Theo said he wasn't going to deal with an email-list or embargoes prior to that. Marc Espie has said he thinks it's a good thing that the KRACK embargo was broken early.


That's not how it happened, that's the narrative you're spinning, certainly.

https://twitter.com/vanhoefm/status/921425715903463425


Please explain how that is not what happened? That tweet does not contradict me in the slightest.

In fact, your original link is quite explicit.

>Then he got CERT (and, thus, US gov agencies) involved and had to extend the embargo even further until today. At that point we already had the ball rolling and decided to stick to the original agreement with him, and he gave us an agreeing nod towards that as well.

So, stsp pretty specifically says "It got extended, we decided not to follow the new date, and he went 'well, okay'"

https://www.krackattacks.com/#openbsd

>To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.

If OpenBSD did nothing wrong, it seems quite odd that the same person who you are saying was fully on board with it is now explicitly saying he is going to provide late notifications.


Wow, that's some seriously selective quoting from the krackattacks link there. The one that is relevant to the question of whether or not OpenBSD patched early without permission is this:

> As a compromise, I allowed them to silently patch the vulnerability.

It's pretty easy to argue that OpenBSD doesn't like embargoes, but it's pretty hard to argue that they ignore embargoes and patch whenever they want to. In this specific case, the project asked and received permission to patch early. The fact that the researcher regrets this in hindsight is beside the point.


They were asked to respect the extended embargo from CERT. They argued against doing so. The researcher going "Well, fine, we had previously agreed on this date, so do it" after trying to get them to respect the extension is not the same as the researcher going "yeah man just release it now it's all good."

He regrets coming to that compromise when they pushed back. They still pushed back and did not want to follow the extension.


OpenBSD had no idea who the other insiders were, only that it received a patch from the researcher, and the go-ahead to fix an important security problem. Suggesting that the correct response was to sit on the patch for months leaving users exposed to a security bug is unreasonable to place on any open source project.

You should read the rest of what you linked, and check the dates carefully.


Yes or no: Was OpenBSD asked by the researcher to respect the CERT requested embargo extension?


Denying a request you haven't agreed to isn't breaking an agreement.


It's still irresponsible in the face of everyone else agreeing to it. The researcher informed them in good faith, they did not return it when the situation changed.


Hmm, not sure what exactly happened with [1] (remotely exploitable vulnerable in OpenSSH in 2006). Did the OpenSSH team follow responsible disclosure there?

[1] https://www.openssh.com/txt/preauth.adv




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: