You know what almost all those examples have in common? They don't generally run user code, so are very unlikely to be running non-vetted code. I wouldn't be surprised if the majority of them don't bother with the fix because of the low chance of being affected and potential performance cost.

When it comes to operating systems that have a large base of users and may run unvetted code, the big candidates for that are operating systems that have home users downloading and running software or in the browser, and shared environments such as shell servers, shared hosting providers and virtual services providers. FreeBSD's common industry use cases and low end-user use mean it's much less exposed to this particular problem.

Edit: grammar, typoo and clarity fixes.

In this particular case, I agree, but it does suggest there should be a workflow for notifying the FreeBSD team of bugs, and I don't see what harm using it here would have caused.

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.

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.

You act as though they don't run code exposed to the internet that could be used to leverage this privilege escalation. Talk about short sighted...