Appreciate it. Far as lack of knowledge, a brain injury in an accident cost me most of my hands-on IT skills and many details in INFOSEC. Among other things... However, the stuff I did repeatedly, like high-level security engineering and assessments, stays with me. Barely relevant here even though it makes plenty of sense that you'd think that. The short-cut around it is the concept of burden of proof in INFOSEC: one is expected to back up their big, security claims with evidence rather than everyone else expected to disprove them.

I certainly could dig back into OpenBSD (and C) to fully understand its current situation, its code, its mitigations, every source change from vulnerability 2, and so on. Those details could benefit OpenBSD in form of contributions I attempt or the reader following along to get a better picture of insides. However, it's not necessary for evaluating my concern about the 2 vulnerability claim. We can cleverly cheat around all that knowledge by going straight to fundamentals and claim itself. Then, only acquiring (me) and/or applying (others) that knowledge if the specialist skill turns out to be required. Others and I did this with success when drowning in product and project security claims with finite time to review them. Let's apply that.

"instead of reasoning about all theoretical directions OpenBSD could have taken."

My main question is a simple, concrete one that I shouldn't have to investigate at all: what evidence is there that there have only been 2 exploitable flaws in all OpenBSD releases? To claim this, there would have to be a tracker of every defect fixed in OpenBSD since its inception, an analysis of each one's exploitability, and a result saying only two were exploitable. There's trackers like that for many projects. Where's that record for OpenBSD or, to save you time, do they even analyze every bug for exploitability?

If that doesn't exist or that analysis wasn't done, then the only 2 vulnerability claim can be rejected immediately because it wasn't proven. Instead, the claim becomes "Of all X defects found, people only showed two were exploitable remotely. (Optionally) That's a defect ratio of X per Kloc with vulnerability ratio of Y per Kloc. (Not optional) The rest either weren't assessed for severity or were shown harmless." Alternatively, the claim is totally false if even one security fix for a remote attack was done after the 2nd vulnerability was fixed. It would have to be changed to a maybe pending further, specialist analysis. This isn't theoretical: it's a direct implication of the claim they're making, an extraordinary implication, and one which deserves concrete evidence to back it.

So, I encourage people to reject it until they have that evidence and in a way they can share easily. If I have time or resources, I might attempt a thorough assessment of OpenBSD in terms of design or code. A past study I did comparing it to prior secure UNIX attempts showed some things it's missing where there's surely issues. It has some other attributes, esp code quality & protections, that help it more than others (including old ones). Nonetheless, the issue I have is an extraordinary claim that pops up repeatedly in discussions over OpenBSD vs whatever with no evidence to back it and high chance of failure. See the problem? Also, do you see how I don't need to be an OpenBSD developer to spot it?