6 ms·
In C this kind of issue is so common it wouldn't raise to the status of "CVE". People would just shrug and say "git gud".
by jrimbault 9mo ago
In C this kind of issue is so common it wouldn't raise to the status of "CVE". People would just shrug and say "git gud".
- uecker 9mo agoThis is certainly not true. But also arguments about "common" are completely misleading as long as there is many orders of magnitude more C code than Rust code.
- Certhas 9mo agoMaybe you haven't been paying much attention in this space. Google found empirically that error density in _unsafe_ Rust is still much lower than in C/C++. And only a small portion of code is unsafe. So per LOC Rust has orders of magnitudes fewer errors than C/C++ in real world Android development. And these are not small sample sizes. By now more code is being written in Rust than C++ at Google: https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html https://security.googleblog.com/2025/11/rust-in-android-move... But don't take my word for it, you can hear about the benefits of Rust directly from GKH: www.youtube.com/watch?v=HX0GH-YJbGw There really isn't a good faith argument here. You can make mistakes in Rust? No one denies that. There is more C code so of course there are more mistakes in C code than in Rust? Complete red herring.
- bgwalter 9mo ago[flagged]
- 0dayz 9mo agoWhat does bias have to do with empirical evidence? Disprove that than driveling about non-tech stuff.
- inejge 9mo ago> Why don't they use qmail as an example? Perhaps because qmail is an anomaly, not Android? To remain relatively bug-free, a sizeable C project seems to require a small team and iron discipline. Unix MTAs are actually pretty good examples. With qmail, for a long time, it was just DJB. Postfix has also fared well, and (AFAIK) has a very small team. Both have been architected to religiously check error conditions and avoid the standard library for structure manipulation. Android is probably more representative of large C (or C++) projects one may encounter in the wild.
- AlotOfReading 9mo agoWhat about qmail? No one runs qmail and no one is writing new C with that kind of insanely hyperconservative style using only world-class security experts. And it still wasn't enough. qmail has seen RCEs [0, 1] because DJB didn't consider integer and buffer overflows in-scope for the application. [0] https://www.guninski.com/where_do_you_want_billg_to_go_today_4.html https://www.guninski.com/where_do_you_want_billg_to_go_today... [1] https://lwn.net/Articles/820969/ https://lwn.net/Articles/820969/
- uecker 9mo agoHey, it was my point that the number of CVEs is red herring. And no, I do not care or even believe what Google says. There are so many influencing factors.
- tialaramex 9mo agoI would expect that the largest factor is cultural, and of course it's possible to inculcate safety culture in a team working on a C or C++ codebase, but it seems to me that we've shown it's actually easier to import the culture with a language which supports it. Essentially Weak Sapir–Whorf but for programming languages rather than natural languages. Which is such a common idea that it's the subject of a Turing Award speech. Because the code you read and write in Rust usually has these desirable safety properties, that's how you tend to end up thinking about the problems expressed in that code. You could think this way in C, or C++ but the provided tooling and standard libraries don't support that way of using them so well.
- uecker 9mo agoI also think that the largest factor is cultural. But my conclusion from this is not that one should import it with a new language while pretending achieving similar results is not possible otherwise. This just gives an excuse for not caring for the existing code anymore, which I suspect is one reason some parts of the industry like Rust ("nobody can expect us to care about the legacy code, nothing can be done until it is rewritten in Rust")
- Certhas 9mo agoOf course highly correct C code is possible [1]. But ADA makes it easier. Rust makes it easier. You can write anything in any language, that is _not_ the argument. How could you plausibly advocate for a culture that invests a lot of effort [1] into making codes correct, and not also advocate for tools and languages that make it easier to check important aspects of correctness? A craftsman is responsible for his tools. Using subpar tools with the argument that with sufficient knowledge, skill and an appropriate culture you can overcome their shortcomings is absurd. Rust is also often not the right tool. I looked at it fairly deeply some years ago for my team to transition away from Python/C hybrids, but settled on a fully garbage-collected language in the end. That was definitely the right choice for us. [1] e.g. MISRA C, or https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...