Comment by johnisgood
4 days ago
Use static analysis (Coverity, Coccinelle, sparse), enable KASAN/UBSAN, follow the SEI C Coding standard or MISRA C, and rely on the review process.
Many popular C projects do really well. Projects that you probably use.
Memory-safe languages eliminate vulnerability classes, but well-engineered C has proven viable for security-critical <insert whatever you want> infrastructure. The real question is whether the framework maintains that standard, not whether C is inherently unsuitable, thus the security concerns are legitimate but not absolute.
I think you are being a bit too dismissive, and your comment puts nothing concrete on the table.
You CAN write good code in any language. The issue is, as you say, that memory-safe languages eliminate entire vulnerability classes, vulnerability classes that are among the most trivially exploitable.
Can write safe code does not mean always writes safe code. A web server needs to be safe code, always.
This tired, flamewar-prone argument of gatekeeping new code in C/C++. Oh the irony coming from someone who wrote this some days ago:
> One of the highest priorities for the HN algorithm is to promote good interactions and discourage bad interactions. The logic is if you have a lot of people bickering with each other, regardless of the topic, it normalizes bad behavior. HN is trying to sustain itself as a forum with great discussions.
I notice you chose to attack me rather than attacking the assertion that memory-safe languages are inherently safer than memory-unsafe languages like C. Yes, you CAN write memory safe code in C. You DO write memory safe code in languages like Java, Python, PHP, and C#. Critically, the maintenance programmer also writes memory safe code when working in a memory safe language. The maintenance programmer is not guaranteed to write memory safe code when working in a language like C.
If any of the above is incorrect, I'm interested in learning more.
4 replies →
This response is right on fundamentals (more at https://news.ycombinator.com/item?id=45340298) as evidence that they want the same things that you (and we!) do, and base your response on that.
Nearly everyone here wants great discussions; the problem is that we all underestimate the provocations in our own comments, or even just don't see them at all. Meanwhile the provocations in other people's comments often land much harder on us as readers. Say the skew is 10x in each direction—that leads to a 100x distortion. This "100x problem" is probably at the root of most interpersonal glitches here (and not only here). Unfortunately, it seems to be a deep and universal bias.
I know I am not supposed to engage here, but... you can write "unsafe" code in many languages. Logic bugs are extremely common, for one. So are you implying that there exists a language where someone "always writes safe code"?
Indeed, a web server needs to be "safe". How do you know this project is not safe? Have you even tried it, let alone review it, or did you just see "in C" and automatically assumed it is not a safe web framework?
I am pretty sure the author of this project is thrilled to wait for you to submit issues or even PRs.
Logic bugs can exist in any language. Buffer overruns, unallocated memory uses, use after free, pretty much all of the first generation of internet vulns, those are signs the code was written in a non-memory managed language.
The fact that you CAN write memory safe code in C does not mean all maintenance programmers of your project will always write memory safe code in all their commits.
Memory managed languages unquestionably reduce the surface area of bugs one has to worry about, and in particular they eliminate the class of vulnerabilities that was most prevalent in web servers prior to the widespread adoption of memory safe languages.
2 replies →