4 ms·

OpenBSD tracks 100% of exploits/CVEs, as well as patches in their daily change log. See: http://www.openbsd.org/plus.html http://www.openbsd.org/plus.html, htt

OpenBSD tracks 100% of exploits/CVEs, as well as patches in their daily change log. See: http://www.openbsd.org/plus.html http://www.openbsd.org/plus.html, http://www.openbsd.org/plus58.html http://www.openbsd.org/plus58.html, http://www.openbsd.org/plus57.html http://www.openbsd.org/plus57.html, etc... There have been no remote exploits in the last 8 years in the default install.

nickpsecurity 11y ago
That conclusion doesn't follow from the links unless they attempted to produce exploits from each potentially, exploitable defect to confirm or reject whether it was a vulnerability. Like what happens with disclosures in many projects. The truth is that they've fixed many problems in the kernel in the last 8 years which may or may not have been exploitable. They're only sure about two of them with a policy to not check the rest as their time is better spent fixing everything and moving on. I agree with that approach but it makes their 2 vulnerability claim impossible it wasn't tested on defect data. My theory is supported by another post: https://news.ycombinator.com/item?id=10337807 https://news.ycombinator.com/item?id=10337807 So, I'm dismissing their claim entirely and will counter it with their claims linked above along with my argument. However, even without that claim, the OpenBSD team can still make a great argument based on their QA processes and track record in fixing things as you linked. It will certainly have fewer 0-days than anything else which is why I told another OpenBSD developer I recommended Xen projects use it for Dom0 wherever possible. Btw, thanks for the links. It answers the question about their defect tracking in general. Lots of detail in there and evidence of their QA working. As I expected. I'm keeping it to share if the topic comes up in another discussion.

nickpsecurity 11y ago

That conclusion doesn't follow from the links unless they attempted to produce exploits from each potentially, exploitable defect to confirm or reject whether it was a vulnerability. Like what happens with disclosures in many projects. The truth is that they've fixed many problems in the kernel in the last 8 years which may or may not have been exploitable. They're only sure about two of them with a policy to not check the rest as their time is better spent fixing everything and moving on. I agree with that approach but it makes their 2 vulnerability claim impossible it wasn't tested on defect data. My theory is supported by another post: https://news.ycombinator.com/item?id=10337807 https://news.ycombinator.com/item?id=10337807 So, I'm dismissing their claim entirely and will counter it with their claims linked above along with my argument. However, even without that claim, the OpenBSD team can still make a great argument based on their QA processes and track record in fixing things as you linked. It will certainly have fewer 0-days than anything else which is why I told another OpenBSD developer I recommended Xen projects use it for Dom0 wherever possible. Btw, thanks for the links. It answers the question about their defect tracking in general. Lots of detail in there and evidence of their QA working. As I expected. I'm keeping it to share if the topic comes up in another discussion.