5 ms·

> Not as a defense of Google, but what's so wrong about Google not contacting FreeBSD? It's obvious that not all operating system vendors could be contacted (sh

> Not as a defense of Google, but what's so wrong about Google not contacting FreeBSD? It's obvious that not all operating system vendors could be contacted (should they be contacting small hobbyist operating system projects? What about small niche commercial ones?), so choices of who to contact and when had to be made. > I understand why BSD devs are upset, but the complaining comes across as exactly what it is, whining they didn't get treated like the big boys. It sucks. Linux used to be right there with you, and neither got any special treatment, but times have changed. Not notifying the FreeBSD devs is bad for the entire internet. The Netflix open connect CDN is FreeBSD and pushes 37% of North American downstream traffic[1]. Limelight one of the big CDN providers use FreeBSD for it's edge network[2]. Some of the DNS servers for .com and .net are FreeBSD[3] Juniper routers run FreeBSD[4] PS4s run a modified FreeBSD[5], the Apache foundation runs a lot of there infrastructure on FreeBSD[6]. Whatsapp with it's billion plus users run on FreeBSD servers[7]. None of those things should be vulnerable to known bugs if we want a safer internet. So notifying the FreeBSD devs 6 months late did the entire internet a disservice regardless if you use FreeBSD directly or not. [1] http://appleinsider.com/articles/16/01/20/netflix-boasts-37-share-of-internet-traffic-in-north-america-compared-with-3-for-apples-itunes http://appleinsider.com/articles/16/01/20/netflix-boasts-37-... [2] https://www.freebsdfoundation.org/testimonial/limelight-networks/ https://www.freebsdfoundation.org/testimonial/limelight-netw... [3] https://www.freebsdfoundation.org/testimonial/verisign/ https://www.freebsdfoundation.org/testimonial/verisign/ [4] https://www.juniper.net/documentation/en_US/junos/topics/concept/understanding-junos-kernel-freedbsd10.html https://www.juniper.net/documentation/en_US/junos/topics/con... [5] https://www.theregister.co.uk/2013/11/16/sony_playstation_4_kernel/ https://www.theregister.co.uk/2013/11/16/sony_playstation_4_... [6] https://www.freebsdfoundation.org/testimonial/the-apache-software-foundation/ https://www.freebsdfoundation.org/testimonial/the-apache-sof... [7] https://www.freebsdfoundation.org/testimonial/whatsapp/ https://www.freebsdfoundation.org/testimonial/whatsapp/

kbenson 9y ago
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.
- stordoff 9y ago
  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.
  - kbenson 9y ago
    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-Security-Advisory-Intel-Security-Findings https://help.joyent.com/hc/en-us/articles/115015938847-Secur...
    - 2trill2spill 9y ago
      > 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?
      - kbenson 9y ago
        > 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.

kbenson 9y ago

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.

stordoff 9y ago
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.
- kbenson 9y ago
  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-Security-Advisory-Intel-Security-Findings https://help.joyent.com/hc/en-us/articles/115015938847-Secur...
  - 2trill2spill 9y ago
    > 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?
    - kbenson 9y ago
      > 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.