Exactly the kind of meaningless statement I was talking about. You've neither proven they work in isolation nor shown they're a strong combination against determined attackers. Almost all of those people are hitting Windows, Linux, iOS, and Android due to market share. Im not sure we've even seen thorough test of OpenBSD's defenses.
"suggesting OpenBSD's mitigations aren't the strongest in their class clearly needs some proof on your part"
Let's try a few memory or stack issues. SPARK can prove the absence of most of them. Concurrent Pascal and Eiffel could for concurrency. Rust can for dynamic memory and concurrency. SAFEcode does for many C-related errors. Example uses are in Muen, Redox, and SVA-OS. Softbound + CETS goes further with total spatial and temporal safety for C but not in OS's yet.
These are all stronger than OpenBSD techniques for similar use cases. Different tradeoffs involved in using them but definitely stronger. I mean, full safety without GC is strongest you can get in memory errors. Although SPIN OS did it in Modula-3 with GC and type-safe linking too.
"and shocking, they pioneered that too.. having created anoncvs."
Your lack of research is apparent as the first, secure OS with source was Burroughs B5000. It was proprietary but shipped source. Had stack checks, bounds checking, pointer protection, OS in high-level language, compile-time checks for function calls, and run-time checks for invalid arguments. Started high-assurance security by addressing root causes of most known issues... in 1961.
It's also not easy to figure out OpenBSD security effectiveness looking at source. The safer languages like Modula-3 or techniques of B5000/JX-OS/Genode are easy to follow since they are simple & fully preventative. Verify that then the rest inherits its properties if used or interfaced certain way. Not so with OpenBSD's scattered mechanisms: requires much more analysis given use of C and stuff in kernel mode.
Finally, bringing up AnonCVS, you might want to look at David Wheeler's Software Configuration Management security page to see what high-security requires in that. Shapiro's OpenCM (in architecture) or competing Aegis (features) were ahead in many ways with OpenBSD's SCM tactics not registering a blip due to missing requirements on Wheeler et al's lists. I even watched them replaced a distribution tool known to resist NSA per Snowden leaks for a simpler, but unproven, one.
OpenBSD has proven great at configuration, code quality, and minimalism. Burden of proof is still on it in terms of security engineering practices vs other methods or OS's. It's never been proven from requirements to methods to results. Fine with me as it has it's uses, esp where 0-days being low is top priority. Best not to pretend it is something it's not vs making the case with evidence as I described.
There's a lot of security research going on at lots of places in all sorts of ways and that's great. But most of it results in better theoretical understanding. It doesn't result in an OS that can be used on commodity hardware in a production context. Good luck running Firefox on top of a some research OS written in Modula 3.
I just gave that as an example to illustrate the point about those security measures. There's others in real OS's and products in production now plus more that existed decades into the past. And quite a few, including one I named, can handle Firefox. Good, wild guess though as untrustworthy browsers designed for untrustworthy UNIXen are hard. ;) Look up OP2 Web Browser or IBOS Illinois Browser Operating System next time if you want architectures designed for secure OS's. Chrome's security was a knockoff of a predecessor of one.
Exactly the kind of meaningless statement I was talking about. You've neither proven they work in isolation nor shown they're a strong combination against determined attackers. Almost all of those people are hitting Windows, Linux, iOS, and Android due to market share. Im not sure we've even seen thorough test of OpenBSD's defenses.
"suggesting OpenBSD's mitigations aren't the strongest in their class clearly needs some proof on your part"
Let's try a few memory or stack issues. SPARK can prove the absence of most of them. Concurrent Pascal and Eiffel could for concurrency. Rust can for dynamic memory and concurrency. SAFEcode does for many C-related errors. Example uses are in Muen, Redox, and SVA-OS. Softbound + CETS goes further with total spatial and temporal safety for C but not in OS's yet.
These are all stronger than OpenBSD techniques for similar use cases. Different tradeoffs involved in using them but definitely stronger. I mean, full safety without GC is strongest you can get in memory errors. Although SPIN OS did it in Modula-3 with GC and type-safe linking too.
"and shocking, they pioneered that too.. having created anoncvs."
Your lack of research is apparent as the first, secure OS with source was Burroughs B5000. It was proprietary but shipped source. Had stack checks, bounds checking, pointer protection, OS in high-level language, compile-time checks for function calls, and run-time checks for invalid arguments. Started high-assurance security by addressing root causes of most known issues... in 1961.
It's also not easy to figure out OpenBSD security effectiveness looking at source. The safer languages like Modula-3 or techniques of B5000/JX-OS/Genode are easy to follow since they are simple & fully preventative. Verify that then the rest inherits its properties if used or interfaced certain way. Not so with OpenBSD's scattered mechanisms: requires much more analysis given use of C and stuff in kernel mode.
Finally, bringing up AnonCVS, you might want to look at David Wheeler's Software Configuration Management security page to see what high-security requires in that. Shapiro's OpenCM (in architecture) or competing Aegis (features) were ahead in many ways with OpenBSD's SCM tactics not registering a blip due to missing requirements on Wheeler et al's lists. I even watched them replaced a distribution tool known to resist NSA per Snowden leaks for a simpler, but unproven, one.
OpenBSD has proven great at configuration, code quality, and minimalism. Burden of proof is still on it in terms of security engineering practices vs other methods or OS's. It's never been proven from requirements to methods to results. Fine with me as it has it's uses, esp where 0-days being low is top priority. Best not to pretend it is something it's not vs making the case with evidence as I described.