That conclusion doesn&#x27;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&#x27;ve fixed many problems in the kernel in the last 8 years which may or may not have been exploitable. They&#x27;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&#x27;t tested on defect data.<p>My theory is supported by another post:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10337807" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10337807</a><p>So, I&#x27;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.<p>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&#x27;m keeping it to share if the topic comes up in another discussion.