Hacker News Reader

Comment by simplotek | Hacker News Reader

> It is one example of gazillions.

It's literally a single memory error in over 12 million lines of code.

What exactly was the point you were trying to make?

> We've somehow as a community just come to accept that linux will be riddled with security vulns.

I'm sorry, your claim is pure nonsense detached from reality. What exactly led you to believe it's reasonable to jump from finding a single memory error among over 12M loc to "riddled with security vulnerabilities"? Linux quite literally dominates the list of most secure OSs. Where exactly do you base your personal assertion?

View on HN

Vulns are found at a roughly uniform rate.

I mean, we can go search the CVE database for the linux kernel. Surely you don't think that this is the only vuln ever discovered there?

> Vulns are found at a roughly uniform rate.

I'm sorry, this means nothing.

As you made extraordinary claims regarding the security of Linux, did you based your personal assertion on any real world comparison between OSes? Because so far you failed to provide any support for your claim, beyond pointing out a mailing list thread on a single memory error in a RC1 within a 12M loc codebase.

What number of vulns would be acceptable to you?

> What number of vulns would be acceptable to you?

Please stop trying to avoid the question.

Either you based your personal assertions on concrete data, or you're just a clueless troll spewing baseless nonsense.

You've repeatedly tried to dance your way out if substantiating your extraordinary claims.

Either you're able to come up with any semblance of support for your claims, or you can't. What is it?

Here are 2,300 CVEs in linux. https://www.linuxkernelcves.com/cves. You can wander through and look for terms like use-after-free and buffer overflow.

I'm not comparing it to other operating systems. I'm not suggesting that people stop using linux. I'm suggesting that as an industry we need to take this seriously and improve the safety of the most widely used and critical piece of software on the planet.

> Here are 2,300 CVEs in linux.

I'm not sure you're being serious. Do you understand your list is comprised of CVEs that date way back in time as far as 2003?

You're talking about an unfiltered, uncategorized list of reports that were published in last two decades.

At least a couple of entries from a decade ago referred to fixing kernel warnings.

And that's what you chose as the single best smoking gun to support your personal assertions on C?

I have no idea what you want. Will you give me a description of what sort of vuln counts as meaningful to you? First you complain about a single example. Then you complain about a list that is too wide (you can filter it if you want). How am I supposed to do anything useful if I have no idea what you want?

> I have no idea what you want.

I want you to either substantiate your extraordinary claims regarding C's supposedly security issues along with your personal assertions regarding Linux supposedly being riddled with security vulnerabilities. So far you either desperately tried to avoid the questions or put up strawmen. Either you support your claims and present your rationale or your claims are proven to be nonsense.

Nonsense links to 20 years worth of CVEs that boil down to an average of a few dozen random issues in a codebase of over 12M lines of code is complete nonsense, and showcases the exact opposite of your original claims, not to mention that most have zero to do with C at all.

So exactly where do you base your personal assertion that C is somehow riddled with security issues? Nowhere?

People like you need to either open your eyes and think through your baseless beliefs or stop being disingenuous. The world is very different than the bullshit claims that pops up in your Twitter feed.

I don't think anyone believes that Linux will be "riddled with security vulns" nor do they think it's acceptable.

It would seem you have a war to wage on C for periodic bugs written by users of the language, and are ignoring the colossal amount of perfectly decent, working, good code written in C and C++.

This sort of thing seems to happen whenever there's an article on C/C++ and it's wearisome. Many people suddenly appear and proclaim that the languages are terrible and should die and mumble something about memory safety, when I myself haven't got any problems writing memory-safe C++ and haven't had any problems for decades.

Sure, some others do but it doesn't mean the LANGUAGE is terrible; it means the USERS of the language make mistakes. On further investigation, a lot of the vocal haters of C++ turn out to not really use the language that much and therefore means the vocal whining about the language has as much relevance as me complaining about masculine/femenine/neuter when I get der/die/das wrong in German when I only learned it at school decades ago and never ever use it - that is, completely irrelevant. People would rightly roll their eyes if I started complaining about der/die/das when I used it wrong in a sentence.

As a simple analogy, whenever there's a car crash we don't see thousands of people saying that cars should be banned and replaced by trains because "cars are dangerous!"; we understand that the USERS of the cars are at fault, NOT the cars themselves. The same is true with C/C++ - you can make mistakes but you can make dumb mistakes in ANY language. That's why programming is a practiced skill and not something you learn overnight.

There exist C and C++ projects that have zero memory safety vulns. There also exist C and C++ projects that don't operate on untrusted data and so the consequences of a memory safety error are just crashes.

I don't believe that the Chrome or Android developers are especially unique developers. I think that they are a decent proxy for a typical developer on a large project that has significant adversaries. These projects are developed by companies that use better-than-typical tooling to detect vulns.

So I believe that these projects are good examples of what you can expect from ordinary developers using the most recommended safety tools. And... they are full of vulns. If you own a project that is developed entirely by extremely skilled developers or has no significant security characteristics then that's different. But if some person is hiring a bunch of engineers to build and maintain a project that has nontrivial security implications, I think that these projects are decent proxies for the best you can hope for.

I do not believe that it is possible to train an org of developers to safely write a complex project that has nontrivial security implications in C++.

I've been writing C++ code for well over a decade and a significant portion of my career involves static analysis of C++ code. "The haters just don't use C++" is not a compelling argument, in my opinion. In fact, you can find members of the C++ committee who agree that it isn't acceptable for the long term safety of software. Surely they "use the language."

---

Analogies won't ever produce meaningful argumentation here. You can say that Rust is a train and that C++ is a car. I can say that Rust is more like a car with a bunch of modern safety features like lane assist and anti-lock brakes. That's not going to get us anywhere.

Very interesting reply, thanks. I am not sure how much C++ some of the book writers actually write - some of their advice and patterns don't seem usable in the real world.

I should say that the majority of very vocal "haters" that appear on C++ topics appear to not use it and instead just show up to burn the C++ flag in a public space.

Reply on news.ycombinator.com