Comment by kbenson | Hacker News Reader

Comment by kbenson | Hacker News Reader

Parent Full thread

I think the harm is in increasing the parties that have to know about and conform to the embargo.

If FreeBSD should be notified in this case, even though they aren't really in most of the high impact areas, should OpenBSD be notified? What about QNX? What about OpenSolaris? Apparently Joyent got late notification as well[1], and since they actually are a cloud provider, I think they have a much better case for being notified before FreeBSD.

In the end, if there's an information embargo there needs to be a decision about who's in and who's out, and most times there will be some excluded party that really wishes they were included. You can't make everyone happy, but I don't think FreeBSD really needed a huge advance warning, given what it looks like Google's criteria was for notification. The fact the hyperthreading bug that keeps being referenced was handled differently seems to me to be mostly an artifact of a BSD developer finding the bug.

1: https://help.joyent.com/hc/en-us/articles/115015938847-Secur...

That's correct -- we at Joyent had no advanced disclosure. That we have our own operating system (SmartOS) that also serves as the hypervisor in our own public cloud (and that Intel knew and knows all of this) really did/does leave us in a uniquely terrible position. While we have made excellent progress on KIPT for SmartOS/illumos, it is also true that this is very delicate work in the core of the system; that we are forced to do this while vulnerable belies any notion that this was responsible disclosure.

Ah, that's unfortunate. From a little research, the wording from Linode's announcement makes it sounds like they didn't get advance warning, but the wording from Digital Ocean's announcement sounds like they had a few days. I'm not sure how it all worked out, but I agree you guys are a specific case where at least little advance warning would have helped quite a bit, since you can't piggyback on the community nearly as much. Linux providers can at worst just wait for kernel patches and then roll them into production.

> I think the harm is in increasing the parties that have to know about and conform to the embargo.

FreeBSD has conformed to embargoes in the past, telling them would not harm the embargo.

> but I don't think FreeBSD really needed a huge advance warning, given what it looks like Google's criteria was for notification.

You have source for their criteria?

> FreeBSD has conformed to embargoes in the past, telling them would not harm the embargo.

So? Should they be notified of Microsoft windows vulnerabilities just because they've shown they can handle themselves? There has to be a cutoff somewhere. I don't think FreeBSD was in the highly affected subset of use cases. I can imagine others coming to the same conclusion.

> You have source for their criteria?

No, that's what "looks like" in my comment is there for, to imply it's an assumption on my part. They notified chip makers, the large end user OS makers, and many/most the major cloud providers (this probably depends on what you consider major, I don't know if Linode or Digital Ocean were notified, but AWS was, and Joyent wasn't..), which are what I would think the highest impact areas are, as those use cases either require running third party code or often due so (end users and downloaded software or browsers with JS).

To me, that appears like they tried to get the most major players most affected some info.

> So? Should they be notified of Microsoft windows vulnerabilities just because they've shown they can handle themselves? There has to be a cutoff somewhere. I don't think FreeBSD was in the highly affected subset of use cases. I can imagine others coming to the same conclusion.

Seriously what the hell are you talking about? I was saying FreeBSD should be notified of security bugs that effect FreeBSD and not 6 months after other Operating systems are told. I said nothing of Microsoft.

Look at it this way, what's the common case that a FreeBSD install could fall victim to this? Are people commonly running untrusted binaries on those desktops or servers? Is FreeBSD used for a large amount of shared hosting platforms (larger than Linode/Digital Ocean)?

Of those cases where it is more susceptible, what percentage of the overall likely susceptible hosts does that account for? Do you think it's even 0.1%? Even 0.01%?

If that's the case, and I was Google, I'd be just as likely to notify FreeBSD about this when attempting an embargo as some random MS vulnerability.

Your seriously overthinking this. It's as simple as FreeBSD is used extensively across the world, not as much as Linux or Windows, but still millions of servers and appliances run FreeBSD. The next detail relevant is whether FreeBSD devs honor embargoes, which they do. Everything else you have written is just trying to rationalize a bad decision by Google and company.

Reply on news.ycombinator.com