Seems to be found as a part of Patch The Planet [0] which is basically OpenAI giving model access and Trail of Bits using them to find vulnerabilities in OSS projects.
dnsmasq: Codex Security independently identified vulnerable patterns corresponding to four of the six dnsmasq CVEs later fixed in 2.92rel2: CVE-2026-4890 (opens in a new window), CVE-2026-4891 (opens in a new window), CVE-2026-4892 (opens in a new window), and CVE-2026-517
dnsmasq has had so many freaking security holes in 2025 and 2026 that atm I decided to just remove that thing from all my machines.
One bug found is a testament to the great diligence and culture around security of OpenBSD. Especially if you take into account the amount of resources they have been able to achieve this with.
Exactly, the entire AI industry has been trying to create an AI powered security arm race. I am not necessarily blaming them.
Hard to know how much has been thrown into this but I would bet a lot.
So far I have been very surprised we haven't been flooded by those type of announcements. If you look you will always find something and OpenBSD is the top price.
Is this functionality accessible from sandboxed processes? That would make a remote hole much more dangerous when one is found, anyway. The CVE seems to concern SysV semaphores and the pledge(2) man page doesn't seem to mention those.
OpenBSD's security stance being the stuff of legend, I'm curious how many vulns have been found over the last couple months while the big model companies are flaunting their ability to find exploits. It'd be super cool to see it remain tiny.
How many times do you see a bug investigation and it's determined when the bug was introduced?
Do you ever look at the diff that introduced it to understand what was going on in the project at the time? Often, it's in service to a new feature. Sometimes the original change is questionable when you consider you traded it for a severe bug.
Linux is a much larger project receiving changes to tons of systems from lots of different sources. The combined behaviour of those things working together is massively harder to understand and test.
Copyfail being introduced by an optimization made to some random crypto module is a good example of this.
It is quite possible that Linux is the bigger target so it gets more focus. Vulnerabilities there are generally considered more valuable and notable. It would be very difficult to use these numbers to get a meaningful "more secure" stance as there are tons of variables.
If this is just counting the kernel, than Linux is probably a bigger target both i terms of current code size and the amount of churn in the codebase as things change over time. Some of the LPEs might (I've not checked) be in modules that are not commonly loaded, which mitigates their overall significance somewhat.
In the less likely even that this is counting what laymen would call Linux or BSD, i.e. both the kernel and common libraries & tools, then Linux definitely has a wider attack surface. Though some of that surface is shared as some userland parts are common to both.
As with your assessment, I'd agree that these flat numbers without looking for further context don't really give enough for a one-is-more-or-less-secure statement.
Linux also has a ton of extra functionality so I think you’d also have to do some adjustment for “as a user would I be at risk?” versus “can I be a user because it supports my needs?” Some of that would be unfavorable for many users (e.g. a Linux user who is exposed due to a network protocol or file system they’ll never use) but that’s certainly not true of every feature.
Linux also has a ton of bloat. Configuring your own kernel has become an exercise in frustration because documentation is worse "There is no help for this kernel option" and a lot of things are enabled "by default".
I think of it more as their attention to quality in their code:
Given the 'quality' of most code, especially under commercial pressure, it's no surprise that much more effective tools will find many more vulnerabilities. Did OpenBSDs quality approach work in this respect?
A local escalation in BSD is still apparently worth a front page post here, so that seems pretty good.
I wonder why we don’t see more about local escalations in Windows. Of course, being closed source is a little bit of a barrier, but these tools can read assembly pretty well, right?
I’ve heard a couple people say that Microsoft has patched a record number of bugs internally this year so it might be the case that it’s simply more opaque because it’s initiated internally and doesn’t involve a public Git repo or a third-party researcher.
They appreciate technical correctness and they do not exaggerate. Most 'security researchers' are not technically correct and they exaggerate a lot (seeking fame and all).
Dismissing their claims is not being selective, it's just the right thing to do.
sys/kern/sysv_sem.c in OpenBSD through 7.9 has a use-after-free allowing local privilege escalation to root. This is a context switch use-after-free after tsleep in sys_semget().
Would Rust have made this issue impossible by construction? I know Linus has spoken about Rust's promises about memory safety not being equivalently applicable in the kernel domain, so I would be curious to hear any kernel developer's perspectives.
I'm not a kernel developer but I am an embedded firmware engineer.
To be clear: I like Rust. It's great, I use it a lot. But, Rust's memory safety stuff can't really save you from the screwiness of ISRs. Here's a long-winded example:
ST has a nifty double-buffer DMA mode for their ADCs, so you can give the ADC two different buffers, it'll fill one, fire an IRQ, you catch the IRQ and handle the data, meanwhile, it's filling the other buffer, and the IRQ fires again, you handle the data in the other buffer, rinse, repeat.
This allows the ADC to run continuously, monotonically and at very high sample rates, without monopolizing CPU. It's really a terrific design. I used it for a DIY telephony project once to run continuous FFTs on several ADC channels at once.
This is all fun, but the architecture introduces synchronization issues that aren't immediately solvable within Rust's data model.
Okay, so I can't run the FFT from within the ISR, so I delegate that to a thread. Do I have the thread read the DMA buffer directly, and just pray that it does it fast enough that the ADC doesn't loop back around to that buffer until the thread is done?
Or, do I have the ISR copy the buffer into a queue, mitigating the memory corruption risk? Well that seems good, but how do I make the queue visible to both the ISR and the thread? The ISR takes no arguments, it's just an address the CPU jumps to when a thing happens. Thus, the queue has to be global, which means more unsafe blocks and more very un-idiomatic Rust.
side note: in my use case, it actually worked just fine with the thread reading straight from the DMA buffer, even with the risk of memory corruption. But you can imagine use cases where the risk would be more severe, like maybe decoding packets from a serial interface.
Rust is designed to make this type of issue impossible, but that assumes that you can correctly encode object lifetimes in the kernel in a way that allows the compiler to check them.
So I would say that any easy answer like “this would not compile” would just be a guess, because you would want to know more of the particulars in order to answer this question.
I know that this is kind of a non-answer, but if you want to write a kernel in Rust you have to figure out boundaries for where unsafe {} are. In a kernel, there are probably large chunks of unsafe {} and the Rust compiler prevents certain bugs outside unsafe {} assuming there aren’t bugs inside unsafe {} that would prevent the type checker from doing its job correctly.
I would say that Rust has a good story here. The simple form of this wouldn't compile. So you are generally presented two options:
1. Slap a reference count on it.
2. Use `unsafe` to promise the compiler that your code is right.
I would say that 1 is a pretty good habit to have. It may open you to memory leaks if you aren't careful but those are much less bad than a use-after-free or other memory management issues. And of course the fact that this was the route the patch took is a good sign. I think this is a pretty good default option.
Now if performance is a major issue you may consider going to 2, so it is impossible to say "Rust would have prevented this" because if it was originally written in Rust this may have been the route taken. But I think it is still very valuable to make that an explicit choice and obvious to reviewers and readers.
This is the answer I think. The correctness of your safe code is dependent on the diligence of the unsafe code except for the most simple cases. A kernel is going to have a pretty high unsafe to safe ratio compared to most usermode apps.
This really gets to the core of what I think Rust is about, you can add compiler checked constraints to your APIs that your C and C++ code can't. It's up to you to use them effectively. Rust's ability to keep your safe code safe is a measure of the language, but also your architecture. The buck has to stop somewhere for the language to prove safety, Rust lets you decide rather than the language itself.
Not necessarily. Rust safety relies on OS primitives and the error here is in an OS primitive itself (kernel semaphores).
Yes Rust is one language that can be widely deployed in systems programming and potentially avoid classes of memory and ownership errors. No it doesn’t magically solve all the problems. Saying “Rust would fix this” in a hypothetical situation where Rust existed in 1995 or OpenBSD was rewritten from scratch, ok, well maybe. As of today only research kernels and a very small fraction of Linux systems have been written in Rust when we are talking about kernels.
People without systems and embedded programming experience need to sit down.
You might not be able to express the ownership in the way that can be checked statically, so quite possibly this would then be downgraded to a runtime error (that could be handled with a panic)—but not undefined behavior.
I’m not an OS programmer and have been dabbling with OpenBSD’s code for fun. But the fact is that Rust kinda lacks flexibility. Most of the OS is dedicated to building a beautiful lie for programs to run happily, and that’s where C shine.
I shudder to think about the amount of work that it would take to convince the rust compiler that everything is all right. Most hardware interactions is “parse, don’t validate” which means you’ll be pinky-swearing to the compiler.
And for my cursory glances at the code, most structures are handled well, that it’s mostly logic bug (from bad data) instead of bad memory access (which can happen).
In practice you don't convince Rust that everything is right. You let it prove that most of the code is right and you promise it (via unsafe) that the rest is. Ideally these unsafe blocks would be carefully documented, reviewed and ideally enclosed in small modules that makes correctness easier to ascertain.
Rust is no panacea, but in my experience it is far easier to write memory safe code when the risky bits are discouraged and explicitly highlighted rather than every line of code being a possible risk. Humans are pretty bad at reviewing 100 lines of boring looking code (especially if this is one of dozens of patches this week) but much better (although by no means excellent at) reviewing 5 2-line unsafe blocks amongst 90 other lines of code.
OpenBSD wouldn't say anything like that. They're well aware of the 40+ year old codebase's limitations, but accept it because they're not so stupid as to "rewrite it in <other language>" which will bring a million bugs.
They've innovated again and again in the security space and aggressively bring in new security features like pf, OpenSSH, W^X enforcement, pledge(), arc4random(), ASLR, so many other things.
Unlike, say, NPM, which can't even replicate existing packaging systems like yum or apt, and has been plagued with security flaws despite being built entirely out of a memory-safe language. Quite an achievement.
It's difficult to say if a kernel written in rust would not have similar vulnerabilites, because it would be impossible to build a kernel without significant amounts of `unsafe`.
I know a lot about kernel programming. and the last thing as I would ever suggest as being core to kernel programming is that is a specialized discipline that uses different rules and shouldn't be accessible to neophytes. its just code. sometimes the restrictions are unfamiliar, but there is nothing magic going on here.
The OpenBSD project was started in 1995, with ancestry going back further than that. Should they have first invented Rust? Or at what point do you suppose the decades-old codebase should have been completely rewritten?
I think it's important to point out that OpenBSD is not more secure than others, it's just that it's not widely adopted so no one really does audit it.
Oh, hey, a local-user-to-root exploit on OpenBSD. Cool! Those are rare, but not unheard of, unless you're talking about Windows or Linux, where you don't hear much about this bug class, just since it's common-as-rainfall.
Anyway... Does this mean OpenBSD is suddenly less interesting? Nope, it's still pretty much the best-understandable general-purpose OS, ready for your RiiR fork. So, still go for that! Burn a universe or two worth of tokens! For the planet!
Does this mean OpenBSD is suddenly less secure? Nah... Its practical security level was never that much higher than that of its nominal competitors, despite Theo's best attempts, the best of which were replicated elsewhere and majority of it went ignored. The first class counts as "innovations", the rest as "experiments" which, no matter what anyone thinks, is not the same as "failed innovations."
But I digress. Now, go and donate to OpenSSH (because I bet you typed ssh today, didn't you, you rascal?), publish your OxidizedBSD fork, or whatever. Just don't link to that "is OpenBSD secure?" site, because, well, gauche, dude(tte)!
Seems to be found as a part of Patch The Planet [0] which is basically OpenAI giving model access and Trail of Bits using them to find vulnerabilities in OSS projects.
[0] https://openai.com/index/patch-the-planet/
neat, i'm a big fan of trail of bits but apparently missed this announcement. here's their post: https://blog.trailofbits.com/2026/06/22/introducing-patch-th... and a summary of week 1: https://gist.github.com/patch-the-planet/69fd1aa925c8e73edea...
Sidenote but... I read this on that link:
dnsmasq: Codex Security independently identified vulnerable patterns corresponding to four of the six dnsmasq CVEs later fixed in 2.92rel2: CVE-2026-4890 (opens in a new window), CVE-2026-4891 (opens in a new window), CVE-2026-4892 (opens in a new window), and CVE-2026-517
dnsmasq has had so many freaking security holes in 2025 and 2026 that atm I decided to just remove that thing from all my machines.
One bug found is a testament to the great diligence and culture around security of OpenBSD. Especially if you take into account the amount of resources they have been able to achieve this with.
one bug is all it takes
Exactly, the entire AI industry has been trying to create an AI powered security arm race. I am not necessarily blaming them.
Hard to know how much has been thrown into this but I would bet a lot.
So far I have been very surprised we haven't been flooded by those type of announcements. If you look you will always find something and OpenBSD is the top price.
> Only two remote holes in the default install, in a heck of a long time!
https://www.openbsd.org/
https://en.wikipedia.org/wiki/OpenBSD#Security_record
LPE (to root) is serious, but it's not a remote hole.
Is this functionality accessible from sandboxed processes? That would make a remote hole much more dangerous when one is found, anyway. The CVE seems to concern SysV semaphores and the pledge(2) man page doesn't seem to mention those.
OpenBSD's security stance being the stuff of legend, I'm curious how many vulns have been found over the last couple months while the big model companies are flaunting their ability to find exploits. It'd be super cool to see it remain tiny.
According to https://openai.com/index/patch-the-planet/
Linux: 24 LPEs, plus many additional vulnerabilities.
OpenBSD: 1 LPE.
FreeBSD: 7 LPEs, plus many additional vulnerabilities.
Not sure what that says, though. Perhaps the models are more likely to find Linux issues because of the training.
I wonder how many of the Linux the LPEs are related to drivers, which I understand there are more of..
Or Linux development is significantly more active.
This is an external audit. Why would Linux activity make a difference here? Are you theorizing that the churn causes bugs?
> Are you theorizing that the churn causes bugs?
Seems to be the case.
How many times do you see a bug investigation and it's determined when the bug was introduced?
Do you ever look at the diff that introduced it to understand what was going on in the project at the time? Often, it's in service to a new feature. Sometimes the original change is questionable when you consider you traded it for a severe bug.
When more code is written, more bugs are written.
Or, if the act of debugging is removing the bugs from software, then the act of programming is to put the bugs in the software.
Linux is a much larger project receiving changes to tons of systems from lots of different sources. The combined behaviour of those things working together is massively harder to understand and test.
Copyfail being introduced by an optimization made to some random crypto module is a good example of this.
The Linux kernel is generally much larger than OpenBSD which is quite minimal.
But I do agree with you - not directly related to activity.
As another commenter said, number of bugs increases with lines of code changed.
It is quite possible that Linux is the bigger target so it gets more focus. Vulnerabilities there are generally considered more valuable and notable. It would be very difficult to use these numbers to get a meaningful "more secure" stance as there are tons of variables.
If this is just counting the kernel, than Linux is probably a bigger target both i terms of current code size and the amount of churn in the codebase as things change over time. Some of the LPEs might (I've not checked) be in modules that are not commonly loaded, which mitigates their overall significance somewhat.
In the less likely even that this is counting what laymen would call Linux or BSD, i.e. both the kernel and common libraries & tools, then Linux definitely has a wider attack surface. Though some of that surface is shared as some userland parts are common to both.
As with your assessment, I'd agree that these flat numbers without looking for further context don't really give enough for a one-is-more-or-less-secure statement.
Linux also has a ton of extra functionality so I think you’d also have to do some adjustment for “as a user would I be at risk?” versus “can I be a user because it supports my needs?” Some of that would be unfavorable for many users (e.g. a Linux user who is exposed due to a network protocol or file system they’ll never use) but that’s certainly not true of every feature.
Linux also has a ton of bloat. Configuring your own kernel has become an exercise in frustration because documentation is worse "There is no help for this kernel option" and a lot of things are enabled "by default".
The commit logs over the last few months have highlighted when an issue was found by a program. They usually name the submitter and the tool.
I think of it more as their attention to quality in their code:
Given the 'quality' of most code, especially under commercial pressure, it's no surprise that much more effective tools will find many more vulnerabilities. Did OpenBSDs quality approach work in this respect?
A local escalation in BSD is still apparently worth a front page post here, so that seems pretty good.
I wonder why we don’t see more about local escalations in Windows. Of course, being closed source is a little bit of a barrier, but these tools can read assembly pretty well, right?
I’ve heard a couple people say that Microsoft has patched a record number of bugs internally this year so it might be the case that it’s simply more opaque because it’s initiated internally and doesn’t involve a public Git repo or a third-party researcher.
> OpenBSD's security stance being the stuff of legend,
More so their marketing.
What does openbsd marketing look like?
Can anyone find the mailing list thread on this topic (or does it not exist because @security are private mailing list)?
I did find another use-after-free bug from a couple months ago on the mailing list:
https://marc.info/?t=177581065500002&r=1&w=2
If this is a local privilege escalation to root, why can't I find anything on https://www.openbsd.org/security.html ?
Best guess, from the commit message alone[0]: It was fixed as a bug, at the time they didn't have evidence it could lead to LPE
The AI security tool then, retroactively discovered that it could have been used for LPE.
Again, just my guess I could be wrong.
[0] https://github.com/openbsd/src/commit/1957873d2063db11dab780...
OpenBSD has a reputation for being... selective about what they admit is a security-relevant bug.
They appreciate technical correctness and they do not exaggerate. Most 'security researchers' are not technically correct and they exaggerate a lot (seeking fame and all).
Dismissing their claims is not being selective, it's just the right thing to do.
Ah, it was too good to be true, BSD too is becoming rusty.. ahh, what's left?
from the link:
sys/kern/sysv_sem.c in OpenBSD through 7.9 has a use-after-free allowing local privilege escalation to root. This is a context switch use-after-free after tsleep in sys_semget().
Blasphemy
and yet...
Would Rust have made this issue impossible by construction? I know Linus has spoken about Rust's promises about memory safety not being equivalently applicable in the kernel domain, so I would be curious to hear any kernel developer's perspectives.
I'm not a kernel developer but I am an embedded firmware engineer.
To be clear: I like Rust. It's great, I use it a lot. But, Rust's memory safety stuff can't really save you from the screwiness of ISRs. Here's a long-winded example:
ST has a nifty double-buffer DMA mode for their ADCs, so you can give the ADC two different buffers, it'll fill one, fire an IRQ, you catch the IRQ and handle the data, meanwhile, it's filling the other buffer, and the IRQ fires again, you handle the data in the other buffer, rinse, repeat.
This allows the ADC to run continuously, monotonically and at very high sample rates, without monopolizing CPU. It's really a terrific design. I used it for a DIY telephony project once to run continuous FFTs on several ADC channels at once.
This is all fun, but the architecture introduces synchronization issues that aren't immediately solvable within Rust's data model.
Okay, so I can't run the FFT from within the ISR, so I delegate that to a thread. Do I have the thread read the DMA buffer directly, and just pray that it does it fast enough that the ADC doesn't loop back around to that buffer until the thread is done?
Or, do I have the ISR copy the buffer into a queue, mitigating the memory corruption risk? Well that seems good, but how do I make the queue visible to both the ISR and the thread? The ISR takes no arguments, it's just an address the CPU jumps to when a thing happens. Thus, the queue has to be global, which means more unsafe blocks and more very un-idiomatic Rust.
side note: in my use case, it actually worked just fine with the thread reading straight from the DMA buffer, even with the risk of memory corruption. But you can imagine use cases where the risk would be more severe, like maybe decoding packets from a serial interface.
Rust is designed to make this type of issue impossible, but that assumes that you can correctly encode object lifetimes in the kernel in a way that allows the compiler to check them.
So I would say that any easy answer like “this would not compile” would just be a guess, because you would want to know more of the particulars in order to answer this question.
I know that this is kind of a non-answer, but if you want to write a kernel in Rust you have to figure out boundaries for where unsafe {} are. In a kernel, there are probably large chunks of unsafe {} and the Rust compiler prevents certain bugs outside unsafe {} assuming there aren’t bugs inside unsafe {} that would prevent the type checker from doing its job correctly.
I would say that Rust has a good story here. The simple form of this wouldn't compile. So you are generally presented two options:
1. Slap a reference count on it.
2. Use `unsafe` to promise the compiler that your code is right.
I would say that 1 is a pretty good habit to have. It may open you to memory leaks if you aren't careful but those are much less bad than a use-after-free or other memory management issues. And of course the fact that this was the route the patch took is a good sign. I think this is a pretty good default option.
Now if performance is a major issue you may consider going to 2, so it is impossible to say "Rust would have prevented this" because if it was originally written in Rust this may have been the route taken. But I think it is still very valuable to make that an explicit choice and obvious to reviewers and readers.
This is the answer I think. The correctness of your safe code is dependent on the diligence of the unsafe code except for the most simple cases. A kernel is going to have a pretty high unsafe to safe ratio compared to most usermode apps.
This really gets to the core of what I think Rust is about, you can add compiler checked constraints to your APIs that your C and C++ code can't. It's up to you to use them effectively. Rust's ability to keep your safe code safe is a measure of the language, but also your architecture. The buck has to stop somewhere for the language to prove safety, Rust lets you decide rather than the language itself.
The Rust ownership model prevents use after free. This type of a bug would not compile.
Not necessarily. Rust safety relies on OS primitives and the error here is in an OS primitive itself (kernel semaphores).
Yes Rust is one language that can be widely deployed in systems programming and potentially avoid classes of memory and ownership errors. No it doesn’t magically solve all the problems. Saying “Rust would fix this” in a hypothetical situation where Rust existed in 1995 or OpenBSD was rewritten from scratch, ok, well maybe. As of today only research kernels and a very small fraction of Linux systems have been written in Rust when we are talking about kernels.
People without systems and embedded programming experience need to sit down.
I don't think this is about core kernel semaphores but rather the SysV semaphore system calls?
You might not be able to express the ownership in the way that can be checked statically, so quite possibly this would then be downgraded to a runtime error (that could be handled with a panic)—but not undefined behavior.
I’m not an OS programmer and have been dabbling with OpenBSD’s code for fun. But the fact is that Rust kinda lacks flexibility. Most of the OS is dedicated to building a beautiful lie for programs to run happily, and that’s where C shine.
I shudder to think about the amount of work that it would take to convince the rust compiler that everything is all right. Most hardware interactions is “parse, don’t validate” which means you’ll be pinky-swearing to the compiler.
And for my cursory glances at the code, most structures are handled well, that it’s mostly logic bug (from bad data) instead of bad memory access (which can happen).
In practice you don't convince Rust that everything is right. You let it prove that most of the code is right and you promise it (via unsafe) that the rest is. Ideally these unsafe blocks would be carefully documented, reviewed and ideally enclosed in small modules that makes correctness easier to ascertain.
Rust is no panacea, but in my experience it is far easier to write memory safe code when the risky bits are discouraged and explicitly highlighted rather than every line of code being a possible risk. Humans are pretty bad at reviewing 100 lines of boring looking code (especially if this is one of dozens of patches this week) but much better (although by no means excellent at) reviewing 5 2-line unsafe blocks amongst 90 other lines of code.
I thought that parsing implied validation. Is this not the case?
"'Nothing could have prevented this from happening,' say users of only language where this happens" comes to bite OpenBSD.
OpenBSD wouldn't say anything like that. They're well aware of the 40+ year old codebase's limitations, but accept it because they're not so stupid as to "rewrite it in <other language>" which will bring a million bugs.
They've innovated again and again in the security space and aggressively bring in new security features like pf, OpenSSH, W^X enforcement, pledge(), arc4random(), ASLR, so many other things.
Unlike, say, NPM, which can't even replicate existing packaging systems like yum or apt, and has been plagued with security flaws despite being built entirely out of a memory-safe language. Quite an achievement.
It's difficult to say if a kernel written in rust would not have similar vulnerabilites, because it would be impossible to build a kernel without significant amounts of `unsafe`.
Tell us you know nothing about kernel programming and trust stacks while you are at it.
I know a lot about kernel programming. and the last thing as I would ever suggest as being core to kernel programming is that is a specialized discipline that uses different rules and shouldn't be accessible to neophytes. its just code. sometimes the restrictions are unfamiliar, but there is nothing magic going on here.
The OpenBSD project was started in 1995, with ancestry going back further than that. Should they have first invented Rust? Or at what point do you suppose the decades-old codebase should have been completely rewritten?
It's not too late to start now, similar to how Linux did a few years back.
Rumours of Linux being rewritten in Rust are greatly exaggerated.
I think it's important to point out that OpenBSD is not more secure than others, it's just that it's not widely adopted so no one really does audit it.
Oh, hey, a local-user-to-root exploit on OpenBSD. Cool! Those are rare, but not unheard of, unless you're talking about Windows or Linux, where you don't hear much about this bug class, just since it's common-as-rainfall.
Anyway... Does this mean OpenBSD is suddenly less interesting? Nope, it's still pretty much the best-understandable general-purpose OS, ready for your RiiR fork. So, still go for that! Burn a universe or two worth of tokens! For the planet!
Does this mean OpenBSD is suddenly less secure? Nah... Its practical security level was never that much higher than that of its nominal competitors, despite Theo's best attempts, the best of which were replicated elsewhere and majority of it went ignored. The first class counts as "innovations", the rest as "experiments" which, no matter what anyone thinks, is not the same as "failed innovations."
But I digress. Now, go and donate to OpenSSH (because I bet you typed ssh today, didn't you, you rascal?), publish your OxidizedBSD fork, or whatever. Just don't link to that "is OpenBSD secure?" site, because, well, gauche, dude(tte)!
Now I've seen it all.