Humans are bad at writing secure code, and GNOME developers are no exception. GNOME is primarily written using unsafe programming languages where simple mistakes in our code lead to devastating consequences for our users, and we make these mistakes all the time. No matter how much we try, GNOME developers will fail write secure code...
Unsafe languages need to deal with all the same high-level bugs (like access control or SQL injection) in addition to memory safety bugs. C is not trading memory unsafety for some other safety, it’s strictly more unsafe.
Rust does a lot to prevent logic bugs, e.g. error handling can be enforced by the compiler, while C can’t even decide whether returning 0 means OK or false.
Memory unsafety vulnerabilities are exceptional in their unbound scope and severity.
Without arbitrary code execution, the danger is roughly limited to what the code is supposed to do, and plenty of programs have lots of boring code that doesn’t touch anything sensitive. Even if you’re implementing access control, the worst case without RCE is failing open on that endpoint, rather than enabling installation of a rootkit or such.
A memory-safe JSON parser can at worst give you garbage data or heat your CPU or eat your RAM, but it won’t run arbitrary attacker-supplied code. If you’re implementing a widget that queries the current weather, the the worst case is not getting the weather info. In C, the worst case is getting the whole system pwned through a weather info widget. It’s a massive difference in the attack surface.
It’s really really hard to make an off-by-one error in Rust that turns it into a JIT or scripting language.
When a language has an API for executing arbitrary code, misuse of that API leads to arbitrary code execution, duh. That still fits under “the danger is roughly limited to what the code is supposed to do”. But you’re missing the point that in C you don’t need an API for RCE get RCE. In C you have a much larger problem of memory unsafety and UB turning potentially any API into an arbitrary code execution gadget.
I don’t think anyone is arguing that C is as safe as Rust? Certainly my point is that Rust can still have bugs, and those bugs can be security critical.
There is no programming language that can’t have bugs, so such argument doesn’t state anything useful. It’s an empty truism.
OTOH the whataboutist/defeatist responses create a false equivalence. Even though both languages may have bugs: (P(bug | C) > 0) == (P(bug | Rust) > 0) stating it that way obscures the major difference in likelihood of the bugs: P(bug | C) >> P(bug | Rust).
Right but this all started with a discussion of whether or not using llm agents to find bugs is worthwhile or not. Clearly you can write obscure bugs in rust such that LLMs might be a cheap way to find them.
Ok but what if it’s possible to still write bugs in rust?
score 2 · canonical
Most bugs don’t really matter; what matters are vulnerabilities. And Rust is really good at preventing memory corruption bugs.
score 1 · canonical
There are so many vulnerabilities that can be present without memory corruption. Not checking for an access control is perfectly memory safe
score 2 · canonical
All 10 of the OWASP Top 10! https://top10.owasp.org/2025/
score 1 · canonical
Unsafe languages need to deal with all the same high-level bugs (like access control or SQL injection) in addition to memory safety bugs. C is not trading memory unsafety for some other safety, it’s strictly more unsafe. Rust does a lot to prevent logic bugs, e.g. error handling can be enforced by the compiler, while C can’t even decide whether returning 0 means OK or false.
Memory unsafety vulnerabilities are exceptional in their unbound scope and severity.
Without arbitrary code execution, the danger is roughly limited to what the code is supposed to do, and plenty of programs have lots of boring code that doesn’t touch anything sensitive. Even if you’re implementing access control, the worst case without RCE is failing open on that endpoint, rather than enabling installation of a rootkit or such.
A memory-safe JSON parser can at worst give you garbage data or heat your CPU or eat your RAM, but it won’t run arbitrary attacker-supplied code. If you’re implementing a widget that queries the current weather, the the worst case is not getting the weather info. In C, the worst case is getting the whole system pwned through a weather info widget. It’s a massive difference in the attack surface.
score 2 · canonical
Which is why log4shell was impossible to exploit in the memory safe languages Java and shell.
These sorts of things are called weird machines because they’re really weird.
score 1 · canonical
It’s really really hard to make an off-by-one error in Rust that turns it into a JIT or scripting language.
When a language has an API for executing arbitrary code, misuse of that API leads to arbitrary code execution, duh. That still fits under “the danger is roughly limited to what the code is supposed to do”. But you’re missing the point that in C you don’t need an API for RCE get RCE. In C you have a much larger problem of memory unsafety and UB turning potentially any API into an arbitrary code execution gadget.
score 1 · canonical
I don’t think anyone is arguing that C is as safe as Rust? Certainly my point is that Rust can still have bugs, and those bugs can be security critical.
score 1 · canonical
There is no programming language that can’t have bugs, so such argument doesn’t state anything useful. It’s an empty truism.
OTOH the whataboutist/defeatist responses create a false equivalence. Even though both languages may have bugs:
(P(bug | C) > 0) == (P(bug | Rust) > 0)stating it that way obscures the major difference in likelihood of the bugs:P(bug | C) >> P(bug | Rust).score 1 · canonical
Right but this all started with a discussion of whether or not using llm agents to find bugs is worthwhile or not. Clearly you can write obscure bugs in rust such that LLMs might be a cheap way to find them.
score 1 · canonical