31–40 of 170 posts
Earlier quoted context omitted.
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?
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.
[flagged]
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.
Earlier quoted context omitted.
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?
But I do agree with you - not directly related to activity.
Earlier quoted context omitted.
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 fro…
If this is a local privilege escalation to root, why can't I find anything on https://www.openbsd.org/security.html ?
OpenBSD has a reputation for being... selective about what they admit is a security-relevant bug.
Dismissing their claims is not being selective, it's just the right thing to do.
Earlier quoted context omitted.
This is an external audit. Why would Linux activity make a difference here? Are you theorizing that the churn causes bugs?
The Linux kernel is generally much larger than OpenBSD which is quite minimal. But I do agree with you - not directly related to activity.
Earlier quoted context omitted.
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.
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.
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 t…
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.
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.
More so their marketing.
[flagged]
Tell us you know nothing about kernel programming and trust stacks while you are at it.