[johnisgood]

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.

[yodon]

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.

[hu3]

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.

[yodon]

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.

[dang]

What was incorrect (to use your word) in your posts in this thread was your misalignment with the intended spirit of the site. You responded with generic/shallow objections to someone's creative work. That's one of the failure modes of internet discussion, which is why both the HN guidelines (https://news.ycombinator.com/newsguidelines.html) and the Show HN guidelines (https://news.ycombinator.com/showhn.html) ask commenters not to do this.

It's true that the repliers crossed into the red as well, but fundamentally that's a healthy immune response going a little too far.

[yodon]

dang - thanks for being the incredible mod that you are. Genuinely hoping you one day write a book or give a talk on effective communication. Your words, even when they amount to "dude, you screwed up", are always informative and inspiring.

[dang]

Thanks for the kind reply! I'm always surprised when people react so nicely to one of those. It lands, and I appreciate it.

[hu3]

There's nothing to dispute in your assertion, because you're technically correct.

However it's just not constructive and repetitive. You're basically walking into a bar and yelling that alcohol is unhealthy.

[dang]

This response is right on fundamentals (more at https://news.ycombinator.com/item?id=45530668) but unhelpful in approach, and ends up breaking the HN guidelines in its own right.

Rather than flaming someone for not responding in the intended HN spirit, and invoking their recent post as a gotcha, it would be better to take that post (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.

[johnisgood]

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.

[yodon]

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.

[johnisgood]

You're going in circles. You've made the same point three times now without adding anything new.

Yes, memory-safe languages eliminate vulnerability classes. I said that in my first reply. Yes, people make mistakes in C. Obvious. None of this tells us anything about this specific web framework.

You dismissed it as "a terrible idea" based on the language alone. That's lazy analysis. Either review the actual code and find the bugs, or admit you're just cargo-culting the "C bad" narrative without looking at the implementation.

Have you actually examined this codebase or not?

[yodon]

The project is a framework for building applications on top of. The issue isn't the framework code. It's the application layer code that gets written and maintained for years to come on top of what may well be a brilliantly written framework layer.

Given that you don't disagree that C is an inherently riskier language to write in than memory managed languages, I can only conclude that what you're opposed to is the fact that I'm saying the quiet parts out loud. I'm not saying the quiet parts for you, you know them, I'm saying them for the junior devs who stumble across this page of senior devs waxing poetic about how wonderful C is. Every dev should know how to write C, but it's equally important to know its generally the wrong language to choose for a web server, which is what's being discussed here.

[johnisgood]

My problem is that you talk about insecurity because you saw "in C", yet you have not actually reviewed the code. You simply concluded (allegedly) that it is unsafe because it is written "in C". Review the code first. Written "in C" does not automatically make it unsafe. Do you agree?

That is my only problem.

Yes, I agree that every developer should know how to write C (useful skill, reference implementations should be written in C due to its simplicity), but I do not think that using C for writing a web framework is a bad thing. To each their own. It might have issues, but as I have said, it can be analyzed and reviewed through the methods I have previously said so[1]. I have no clue if this code has any issues, I have not reviewed it myself, so it is for not me to claim either way.

Are we in a disagreement or not?

[1] See https://news.ycombinator.com/item?id=45527495.