Hacker News Reader

Comment by nindalf | Hacker News Reader

> All languages have CVEs, C++ just has more (and C still more); so far in 2024, Rust has 6 CVEs [1], and C and C++ combined have 61 CVEs [2]. So zero isn’t the goal; something like a 90% reduction is necessary, and a 98% reduction is sufficient, to achieve security parity with the levels of language safety provided by MSLs

The author is making a massive assumption that all CVEs are equally serious but they aren't. Opening the Rust links indicates several of them are denial of service, including regular expression denial of service. Not downplaying this, but compare it to the first result in the other link, which involves potential remote code execution (RCE).

Take for example CVE-2022-21658 (https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html) in Rust, related to a filesystem API. It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed. That's why counting CVEs alone is meaningless.

The author concedes that CVEs are not a good metric to measure by, but implies that maybe C and C++ have too many CVEs that shouldn't actually be CVEs and that the C++ community should take more control of CVEs being filed. This is ominous, and makes me fear we might start to see fewer C and C++ CVEs because issues will be closed as "intended behaviour" or "won't fix", like the filesystem issue above.

[1] - https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust

[2] - https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=c++

View on HN

> It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed.

Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all.

Case in point, this was fixed in both major C++ libraries:

https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d...

https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9...

So what C++ community refused to regard this as an issue and refused to fix it? Where is your supporting evidence for your claims?

Saying it was fixed in two of the three C++ standard libraries is irrelevant, the language standard itself specifies that the behavior is undefined.

This would be like saying C++ the language fixed buffer overflows because GCC added bounds checking. Most sensible C++ developers know that you should not depend on undefined behavior to write correct software, and yet your argument that because some implementations (not all) have decided to provide semantics for this, that it's now okay to use it or no longer a problem.

Most sensible developers develop software against compiler specifications, not the standard. Very very little useful software can be implemented strictly within what's offered by the standard.

That's very not a reason to justify the critical shortcomings of a standard, especially so when implementations are known to make their practical safeties regress in the name of they are allowed by the letter. In that context the very culture of C++ normalizers and implementers has to change and the introduction of this paper is a step in the wrong direction in that regard.

Realistically the only improvement to the spec is changing fs races from undefined behaviour to something less program-invalidating. But to what? Unspecified behaviour would require the standard to give a set of possible outcomes which might not be implementable. Implementation defined would still require the compiler to pick and document a specific behaviour which might also not be possible to guarantee.

The only way to provide stronger guarantees is to rigorously define the behaviour of the OS, which is of course not possible. Not even POSIX does that and of course C++ targets beyond POSIX.

The reality is that there are a lot of things that are commonly done that are formally undefined (for example mmap, ldopen, openmp) and the user has to look for details beyond the C++ standard and into other documents (other standards, the compiler manual).

The alternative is a fully defined isolated sandbox, but that would be pointless for a system language and not even Java attempts that.

> Unspecified behaviour would require the standard to give a set of possible outcomes

I don't think there is a requirement that the possible unspecified behaviors are enumerated. The current C++ draft [0] states possible behaviors are "usually" enumerated, but "usually" is not "always", and there's no explicit direction that those behaviors are the only allowable options.

There's also the definition from the C89 spec which doesn't even have that language, only stating that the standard imposes no requirements on the unspecified behavior [1].

[0]: https://eel.is/c++draft/intro.defs#defns.unspecified

[1]: http://port70.net/%7Ensz/c/c89/c89-draft.html#1.6

Or put another way, find a language, any language, that defines all possible scenarios of a file system race condition in a multi threading & multi process system. It's not possible to do such a thing, and of course nobody does. They just avoid using the term "undefined behavior" even though it absolutely is.

Which makes this whole thread absolutely absurd. It's the worst possible example of Rust vs. C++ CVE as the language doesn't get an opinion here at all in the first place

No, it's an excellent example.

Rust issued a CVE, an immediate point release with a fix for the issue and a blog post explaining the problem and what they did.

2 C++ implementations fixed the issue, but no CVE or blog post. No point release either AFAIK.

You harp on the fact that this is undefined in all languages. Yeah sure. But some languages take the report seriously and communicate that to their users. They don't hide behind "spec says UB" or "it's the file system's fault". They take accountability and fix it. Other languages don't because that's the prevailing culture there.

That's what you're missing when you're trying to make it seem like there's no difference between Rust and C++. There's a vast difference in how each community takes security. That's why its meaningless to compare the number of CVEs in both languages. Even if C++ reduced the number of CVEs by 90% it still would not be as secure as Rust because 1 C++ CVE is not the same as 1 Rust CVE.

You're moving the goalposts so fast you could be competing with C++ for prioritizing performance over soundness.

Reminder that your original claim was:

> The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed.

Now it's degraded to just "but there wasn't a CVE or blog post!" which isn't even that relevant to the broader argument of Herb's that all the language guarantees don't prevent logic bugs (hence how Rust was able to have this CVE in the first place). There's a point of "good enough" for the language itself.

Nobody is making any argument that CVE count is the best or optimal metric for anything

I didn't move the goalposts. I was going off my recollection at the time, which was a discussion around the Rust blog post and CVE. Here's a comment from me a day ago saying "I stand corrected" (https://news.ycombinator.com/item?id=39680754).

> Nobody is making any argument that CVE count is the best or optimal metric for anything

Except, you know, Herb Sutter in the article we're supposedly discussing. He's arguing that it's possible to compare Rust and C++ CVEs and that C++ would be just as good as Rust if the CVE counts were similar. If you took the trouble of addressing the substance of my comment that Rust and C++ CVEs aren't comparable, rather than exulting in being technically correct because you found a mistake, you would have realised that.

You're welcome to assume bad faith of me, but that was the substance of my comment. I'm sorry I didn't keep in touch with every commit made to C++ compiler repos and I spoke out of turn. But I never moved the goalposts - those were always fixed on the issue that comparing CVEs between a language that takes security seriously and one that doesn't is a dumb idea.

> Except, you know, Herb Sutter in the article we're supposedly discussing

"Saying the quiet part out loud: CVEs are known to be an imprecise metric. We use it because it’s the metric we have, at least for security vulnerabilities, but we should use it with care. This may surprise you, as it did me, because we hear a lot about CVEs. But whenever I’ve suggested improvements for C++ and measuring “success” via a reduction in CVEs (including in this essay), security experts insist to me that CVEs aren’t a great metric to use… including the same experts who had previously quoted the 70% CVE number to me. "

-Herb Sutter

That's from the article we're discussing and you knew that because you also acknowledged that:

> The author concedes that CVEs are not a good metric to measure by, but implies that maybe C and C++ have too many CVEs that shouldn't actually be CVEs and that the C++ community should take more control of CVEs being filed. This is ominous, and makes me fear we might start to see fewer C and C++ CVEs because issues will be closed as "intended behaviour" or "won't fix", like the filesystem issue above.

So you know that Herb isn't arguing that CVEs are ideal. You instead took a wrong baseline assumption (that C++ didn't care about the FS issue) and turned it into some weird claim that the result will just be the C++ community refusing to fix or acknowledge CVEs in order to drive the count down.

You're arguing two conflicting ideas:

Point 1: C++ is bad because there's no one ensuring CVEs & blog posts are filed for issues

Point 2: C++ is bad because a central CVE would just let them hide the issues they're desperate to hide

Despite your only evidence for either of these being something you made up entirely, as you eventually reluctantly admitted.

Those points aren't contradictory. C++ is actually so terrible that

1. They're underreporting CVEs as of today. You acknowledge that a CVE should have been filed for the FS issue but it wasn't. I say it wasn't because the community has a cavalier attitude towards security and they didn't think it was worthy of a CVE. Nothing you've said contradicts this

2. Herb Sutter argues that there should be more control over what CVEs are filed because he's not happy with the ones being filed today, which may merely be bugs and not vulnerabilities. This may make the situation worse, with even fewer CVEs being filed. That's juking the stats.

Herb does acknowledge that CVEs aren't ideal, but the entire article is based on getting the number of CVEs in C++ down to a level comparable with Rust. He wouldn't have set that as a goal if he truly thought CVEs were meaningless.

By the way, I'm still waiting on the link for the fix in MSVC. Or did you give up on it because you saw steveklabnik's comment where he links to an MSVC maintainer saying there's no point fixing it in MSVC without changing the spec? (https://old.reddit.com/r/cpp/comments/151cnlc/a_safety_cultu...).

> something you made up entirely, as you eventually reluctantly admitted

I didn't make up anything, nor did I admit anything. My information was outdated, and I said I was wrong. You're accusing me of lying when I didn't, which make it hard to interact with you.

I say only this. Don't harp on a mistake I made and admitted to, and instead address the substance of what I said.

1. CVEs between languages aren't comparable (you don't dispute this).

2. C++ community should have filed CVEs for this issue but didn't (you don't dispute this).

3. The lack of CVEs indicates that they have a much lower standard for security.

That sounds like the hallmark of a defective language to me.

Loads of very popular languages don't have formal specifications at all:

* Rust

* Python

* Ruby

* PHP

* TypeScript

Ruby is weirder than that: it has an ISO standard, but that standard is 100% irrelevant.

Funny, Matz mentioned about it in RubyKaigi 2023 keynote, that it was made with the hope that it gets wider adoption in the industry, maybe even used in technical exams. It didn't get the expected result and he felt like it was a waste of time and effort.

I'll have to track that down! This is a bit of a spicy take, but I do think of the Ruby ISO spec whenever people say that Rust needs to have one or else it won't get real adoption...

ISO - and more specifically SC22 of JTC1 which is where a programming language ISO committee would live - is a terrible place to develop anything like this. It's almost designed to be unsuitable, and the insane thing is that JTC1 wasn't even created until 1987. If you told me it was from the 1960s I'd say maybe they didn't know any better, but in 1987 the IETF is already running. WG21 (the C++ Standards Committee, in JTC1/SC22) took until the pandemic forced them to to stop insisting on 100% in-person meetings to make decisions.

Here's my line in the sand: After the Mother of All Demos, if you're trying to agree things internationally and you are physically moving people to a location to do that you're doing it wrong, but maybe you don't know that yet. After JIPS ceases to be a pilot project, not knowing you're doing it wrong means you're grossly incompetent.

Those two dates are somewhat arbitrary, I picked them deliberately but I can entertain other nearby events for the same purpose. In particular if you're in Asia or Africa the JIPS date seems very arbitrary, I pick it because in my opinion this outcome (The United Kingdom's tertiary education will use IP not X.series standards) firmly means the Third Network will be the Internet not the X.25 standard. X.25 can win if only the Americans do IP, but it can't once IP spreads and that's what JIPS is.

I'm far from convinced Rust should have standardization via some SDO, but if it did need that then I'm sure ISO is the last place to go. ETSI isn't great, but it's already better than JTC1. If some corporates insist on an ISO document, mint the document somewhere else and just get ISO to put their stamp on it, have the corp. pay for that - but tell anybody who cares to ignore the stupid ISO document.

You (Steve) undoubtedly know that C++ 23 is a thing, they signed off on it mostly in 2022 and a little bit of 2023, but because ISO is awful actually ISO/IEC 14882:2023 doesn't exist, they are still working through the tedious process of agreeing to publish a document everybody settled on twelve months or more ago.

This process was fine for, I dunno, standardising how the plastic joints fit together on a water pipeline. Maybe it takes a few years to nail down exactly the text, you standardise it, nobody needs to revisit for decades at least. It's stupid for a programming language.

Similar to TypeScript, which has a standard. [1]

Last updated Jan 2016.

[1] https://javascript.xgqfrms.xyz/pdfs/TypeScript%20Language%20...

I could be mistaken but I believe Python has a formal spec, no?

https://docs.python.org/3/reference/index.html

most languages don't even have a specification.

Yes! This is much under appreciated.

Usually, it’s just some core calculus of the language that is rigorously specified and the rest is hand waving.

There are some exceptions like JS.

But even Java has the problem that if you just implement what’s in the spec, you won’t be able to run anything meaningful unless you also do things exactly how the JDK would. You can find out what the JDK does by reading its code and writing test cases and I think that’s what folks do, if they want to be compatible.

UB and memory safety are orthogonal. If we specified formally and super rigorously that a pointer is an integer and that memory is an array of bytes, we could have a UB-free language but memory safety would still be on fire.

> If we specified formally and super rigorously that a pointer is an integer and that memory is an array of bytes, we could have a UB-free language

That's PVI (Provenance Via Integers) and it's a performance disaster. If anything in memory might be pointed to, almost all the nice modern optimisations aren't correct. It is really popular with a certain kind of "Portable assembler" programmer, who typically has no idea how the machine actually works, nor how their language is defined but is very confident the nonsense they're writing ought to do what they wanted it to do.

So, the "bad" news is that you can't have this, your compiler vendor won't make it, and the "good" news is that you'd have hated it anyway which is why they won't make it.

I don't think it is same as PVI, because i) there are a lot of possible non-determinisms still allowed and thus to be exploited, and ii) the specification will have to require only the observational equivalence anyway because every optimization will be invalid otherwise. It should be definitely possible to define a very precise machine without actually mandating PVI.

Everything is memory safe if your only datatype is uint8_t /s

Yup :-)

The issue isn't that C++'s specification has an issue. The issue is that the same issue resulted in no CVE for any C++ vendor. And most languages tend to have 1 reference de facto implementation whereas C and C++ are quite unique in having 2-4 mainstream ones in regular use (& the C++ frontend is ridiculously complex). Java, Python and C# are the only other mainstream languages with a formal spec and only Python that I know of maybe has alternate frontends (there are multiple runtime implementations for C# and Java but I don't believe the language -> bytecode part is different).

JS is maybe closer on this front but it's also quite old & JS is also a mess & a lot of development has shifted to TS as the language for those reasons & TS only has 1 frontend & no formal spec.

There are at least two Java bytecode compilers. Though javac is obviously the "reference", there is also egc. It's used primarily by IDEs and editor plugins (like Eclipse, from whence it came, and the RedHat Java plugin for VS Code).

Still, if memory serves there have been a handful of cases where egc's implementation of the spec differed from javac's with resulting fixes in javac itself (though I don't have sources at hand, so perhaps I misremember).

That is an even more grievous deficiency than an inadequate spec, but it hardly means that a bad spec is good.

> Saying it was fixed in two of the three C++ standard libraries is irrelevant, the language standard itself specifies that the behavior is undefined.

Where does it say that? Please point to the spec that says remove_dir is allowed to have TOCTOU security bugs in a system with multiple processes.

There is a comment below pointing to STL himself saying that it is https://old.reddit.com/r/cpp/comments/151cnlc/a_safety_cultu...

He doesn't cite it, but if there's anyone I'd trust to have correct information here, it's him.

The UB is actually much broader, the standard just says it's UB if there is other software which touches files while you're also touching them, it's basically just always potential UB to run C++ application software with the filesystem API on a multitasking system.

"A file system race is the condition that occurs when multiple threads, processes, or computers interleave access and modification of the same object within a file system. Behavior is undefined if calls to functions provided [...] introduce a file system race."

That's also UB in Rust, Java, C#, etc...

There's no language anywhere where a different process interacting with the file system at the same time isn't UB

How is it UB? The behaviour seems reasonably defined to me in my Rust, my Java, my C#. The people delivering popular implementations of the C++ standard library seemed to feel that not having UB here was a significant Quality of Implementation issue too. The ISO document on the other hand insists it's UB.

I stand corrected that the issue wasn't fixed (https://news.ycombinator.com/item?id=39680006). The issue was fixed, but no CVE by the C++ libraries. That reinforces the point that the author's attempt to equate 1 Rust CVE = 1 C++ CVE isn't valid.

> Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all.

Relevant piece of the standard: http://eel.is/c++draft/fs.race.behavior#1.sentence-2

Officially it's undefined behavior.

And here's a comment from the maintainer of the STL in MSVC regarding this: https://old.reddit.com/r/cpp/comments/151cnlc/a_safety_cultu...

That statement really doesn't support your claim and unsurprisingly Rust has the same basic caveat because of course it does, it's not possible for a language to guarantee exclusive IO access to the filesystem.

https://doc.rust-lang.org/std/io/index.html#io-safety

The Rust docs say something substantively different about safety from what the C++ standard says.

The Rust docs are talking about the safety and soundness of keeping track of the fd ownership. The C++ standard says that FS races are UB.

FS races in Rust are UB as well, they're just scared to say that very explicitly. They hide behind this phrasing:

"Many I/O functions throughout the standard library are documented to indicate what various library or syscalls they are delegated to. "

And just think about it rationally for a second. The FS is implemented by the kernel, which doesn't give a damn what language you're using. So Rust cannot possibly guarantee anything about it. Everything about Rust's FS API is every bit as full of UB as C++'s because it's a shared system with external processes - Rust can't guarantee shit. They just make you go look up what the syscalls are to find out what the guarantees (or lack-thereof) actually are instead.

> Rust can't guarantee shit

And yet, the Rust community takes it seriously, issuing a CVE, a point release and a blog post. You won't find these 3 from all 3 major C++ implementations (clang, gcc and msvc) because they don't take the issue as seriously because their spec says they don't have to.

Rust can't guarantee shit but at least they do shit when there's a problem. They take accountability for their shit.

You keep harping on minor nitpicks, but you can't escape the fact that the C++ community did not take this issue as seriously as Rust did. Therefore it is meaningless to compare CVEs across the two ecosystems, which was the substance of the top level comment.

> because they don't take the issue as seriously because their spec says they don't have to.

And yet they all quickly fixed the issue and nobody tried to hide behind "the spec"

Should there have been a CVE? Probably. But there's no central C++ CVE committee to have done that, either, which to Herb's point there probably should be.

Should there have been a blog post? Probably not. People don't ship their own standard library, so the blog post is low value. What matters is whether or not distros/OS's picked up that fix promptly. Which unfortunately is hard to find out since most Linux distros suck ass at keeping their standard libraries up to date.

> they all quickly fixed the issue

I notice you linked the fixes for clang and gcc. Where's the link for MSVC?

> Should there have been a CVE? Probably.

Glad you agree. But the absence of it proves the point I'm trying to make - they didn't take it seriously enough.

> there's no central C++ CVE committee to have done that, either, which to Herb's point

It actually sounds like Herb wants to reduce the the number of C++ CVEs that are filed, not increase them. He very specifically says that a bug shouldn't be enough, there should be a vulnerability. It sounds like he wants to achieve his goal of fewer CVEs by juking the stats, but who knows.

Even worse, in fact. While one can happily argue (non-)justifications for this till everyone's blue in the face, filesystem interfaces (in UNIX, but with a little magic sprinkle in Windows as well) have always allowed for concurrent access to the same file via two different handles. Open the file twice, and use the two - entirely "independent" objects for any language - filedescriptors to change the contents underneath each other. System behaviour here allows for things that "rust as a language" does not (* - I know about inner mutability but that's a different thing; even the data retrieved from a readonly-opened file can change if a second writeable open happened on it). In the end, programming languages and their standard runtimes depend on the behaviour of the operating system. I actually love that rust exposes this via system-specific traits.

The "extreme" would be to go the "Oberon Way" - write the system for the language that implements the system written in that language. Maybe we'll get "somewhere there" with rust one day. Maybe not. Personally, I don't see the value in it, but mileage may vary.

You pointed at the I/O safety notice in Rust's documentation, but now you've pivoted to saying you were really talking about something different.

But wait a second lets go look at that notice again. Rust is yet again delivering a safety feature C++ just does not have. This actually wasn't in Rust 1.0 -- the safety notice didn't appear then because the I/O safety work landed much later. These safe I/O properties are really useful (even if they're not magic, hence the notice) and C++ doesn't have them.

What's particularly going on here is that on a Unix Rust has types named OwnedFd and BorrowedFd which represent file descriptors, these are quietly just a 32-bit integer with a niche, because -1 isn't a valid file descriptor, that's a niche, so Option<OwnedFd> is the same size in memory as a 32-bit integer.

The result is that Rust gets to do the same trick with file descriptors as it does with pointers - a Rust program working with fds uses the same size data structures as you'd write native C (or thin C++) to work with file descriptors, but where that C or C++ would need to remember to write checks for the -1 file descriptor in Rust that's seamless anyway because it is Option<OwnedFd> so that's None.

On Windows they don't have file descriptors, but they do have Handles, the Handles are much more muddled, and so we can't optimise them as well (actually it's a wonder Windows manages to keep all these balls up in their air they're juggled so frantically, there's a lot of references to Raymond Chen's blog) but again Rust provides I/O safety for these types.

This is the purview of a programming language and Rust does a much better job, I wouldn't have gone out of my way to call attention to it, but you did apparently because you mistook this feature (which C++ doesn't have) for a different feature which C++ is bad at.

Everything you just talked about is unrelated to the issue being discussed. This bug isn't a mismanagement of FD lifecycles, which yes Rust will do more safely out of the box than C++. This bug is a TOCTOU issue ( https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use ) and, more broadly, concurrent access of the file system by multiple processes. Rust cannot guarantee anything about that.

Just because you have an FD and you know it's not -1 and you never forget to check that, that doesn't mean anything at all with respect to the concurrent access to the underlying ionode by multiple process for which that FD references.

Also it's very easy to make the equivalent of an OwnedFd in C++, eg https://cs.android.com/android/platform/superproject/main/+/...

I understand that the original topic was the TOCTOU bug but again, Rust actually makes explicit promises about what happens here, which it deliver via the appropriate filesystem APIs, whereas what the ISO document tells you for C++ is just you get Undefined Behaviour - absolutely anything might happen - the popular implementations do more but that's not what the standard says.

I mentioned what I/O safety really is because you've stumbled onto it while scrabbling to justify the belief that Rust also has UB for the TOCTOU bug.

And while Android's ScopedFd is more or less what you'd do in C++ it has a number of significant differences, which I'd say are disadvantages:

1: Most importantly OwnedFd is part of Rust's standard library.

2: ScopedFd insists on behaving like an integer, which is very typical in C++ but not in Rust. If we want a File Descriptor, who cares that those are "actually" integers? Thus we can compare a ScopedFd to an integer - is this ScopedFd more than ten?

3: And so ScopedFd can represent an invalid file descriptor. We don't own that of course, and it's not really a file descriptor at all, but we can (and Android does) represent it anyway. OwnedFd only represents valid file descriptors, an Option<OwnedFile> represents the wider category of either a valid file descriptor or not if that's what you meant.

4: Android provides a borrowing mechanic here, but of course doesn't have a borrow checker, so again you don't actually get the safety benefit of BorrowedFd.

Not to mention the weird conclusion that since no language has 0, that isn't the goal. I'm not sure I understand the logic that you shouldn't at least _try_ to not have any major security flaws. My interpretation of the CVE counts he mentions is that if your goal is zero, you might end up still having a few, but if your goal is just "few enough that people stop complaining about us being worse than other languages in a similar niche", you probably will end up not hitting that threshold either, which seems like a plausible explanation for how C++ is in this situation in the first place. The fact that he brings up C a bunch also seems like it could be related to this; it sort of feels like he's focusing too much on the idea of security as a competition between languages rather than something that's inherently worthwhile as a goal in its own right.

The point is that trying to hit 0 would be a huge breakage that would fragment the language, and there's no actual evidence to suggest such a thing is actually necessary.

It's like your front door's lock. It doesn't have to be unpickable, unshimmable, absolutely secure. It just has to put up more of a fight than a brick through the window.

I think the problem with this analogy for me is that while you might not care to have your home be 100% impossible to break into, you _do_ want to aim for it to be broken into zero times a year. If my house got broken into 60 times a year for five years, and my neighbors got broken into 6 times a year for the same period, I still think my long-term goal would be to have my home _never_ broken into, even if it meant moving to a different neighborhood.

Right, but security bugs don't all come from the language. They also come from logic errors. That's the "window" analogy here. If the language (door) is no longer the way people are getting into your house, then that's job done for addressing the language and you need other tools to focus on other issues that now are the problem.

right, so what you decide to do is quit your job and never leave the house so no one ever has the opportunity to break into your house.

Does the cost of doing so justify being 100% secure?

most people would say no.

Quit my job? I'm remote bb BD

The best of both worlds: performance and security. Brought to you by Rust. (Even though I actually write C++ from home...)

ok that's a scenario I didn't fully consider, lmao.

but humor aside, the point stands. safety/security is about tradeoffs.

> safety/security is about tradeoffs

I don't disagree with this, but I'm struggling to understand how aiming for zero CVEs would somehow be too onerous a tradeoff when six is reasonable. Assuming that nobody wants to have any CVEs in their codebase, the idea that ending up with six is reasonable but aiming for zero is preposterous sounds like another way of saying "it's easy to accidentally miss six future CVEs in your codebase". If that's the case, how can you have any degree of confidence that by aiming for six, you won't end up with 12 instead?

there's a reason people say things like "actions speak louder than words".

It's easy to say "safety is about tradeoffs" but then when you follow it up with an insistent that no tradeoffs should be made it kind of makes it seem like you're just saying that to appear reasonable rather than actually being reasonable.

Yep yep. A better analogy might be that the door has to eliminate quick, quiet entry to the house since that would deter a huge majority of would-be burglars just due to the vastly increased danger of getting noticed.

We have locks on windows, but rarely bars. We have alarms that trigger sirens, but rarely indoor locks. Eliminate quick and quiet, usually good enough.

Or, to stay within the metaphor, more of a fight than the door of your neighbor.

Yeah.

What I like about the 100% memory safe goal is that it’s a falsifiable goal.

Even the Rust style goal of “you’re memory safe if you do 100% rust and never use unsafe” has the nice property of being falsifiable.

98% memory safe is not a falsifiable goal. It gives the C++ designers the option of never actually fixing the problem while claiming they had by picking a sloppy way of measuring the “%”.

> Not to mention the weird conclusion that since no language has 0, that isn't the goal. I'm not sure I understand the logic that you shouldn't at least _try_ to not have any major security flaws.

He addressed that, the cost of making it to 0 would be too great (C++ would have to break backwards compatibility) so we should try and be inline with other languages instead.

I don't understand why you're acting as if he didn't make the point he made.

> He addressed that, the cost of making it to 0 would be too great (C++ would have to break backwards compatibility) so we should try and be inline with other languages instead.

> I don't understand why you're acting as if he didn't make the point he made.

My confusion is that I'd expect breaking backwards compatibility to either be completely off the table or for the amount of breakage allowed to be up for debate. If you're not willing to break compatibility at all, I feel like the goal should be to shoot as low as possible without breaking anything; if it's possible to get as low as other languages, why stop there? If you're willing to sacrifice some backwards compatibility, why not be willing to break it a little more to eliminate the last few sources of unsafety?

it's not clear to me that you read or understood the article, all of your posts certainly feel as if you didn't.

He explained why 0 isn't the goal, you continue to act as if he didn't. I don't know where else this conversation can go without you going back and better understanding his actual point.

If the discussion requires that I find his explanation convincing rather than being able to think that it's not sufficient, then yeah, I guess there's nowhere else for it to go.

The CVE/CVSS system lacks ability to deal with soundness issues.

If the language or a library promises to catch a mistake, and it doesn’t, that’s not automatically exploitable unless the programmer has actually made that mistake. If there wasn’t a promise in the first place, there would be nothing to report.

Unfortunately, CVE can’t see the difference between reporting a bug, or reporting a theoretical possibility of having a bug that never actually happened.

Frankly, I don't think industry is going to allow soundness issues to ever achieve parity of importance with what we think of as CVEs. There's simply too much code and mindshare around languages that don't worry as much about soundness.

I'm not saying it is right, just that concerns around soundness will likely be hand-waved away. And it is to everyone's detriment.

Or you can flip it around and ask why there isn't a body in the C and C++ community funding tangible advancements in the security and safety problem space the way the Python Foundation and Rust Foundation are.

I don't know about this. There are a lot of people being paid by their companies to work on the C++ committee and on various compiler teams. The author of the post we're discussing is a member of the committee and this article is an attempt to improve the security situation in C++.

So funding isn't the issue. The issue is that the committee has a firm commitment to never introducing breaking changes. This commitment is so firm that it trumps literally any other interest, like making the language memory safe. That's why the author only suggests non-breaking changes in this article.

Lots of people are going to have opinions on whether this approach is the right one for C++'s long term success, but I think we'll only know in 5-10 years.

This :

> So funding isn't the issue.

does not follow from :

> There are a lot of people being paid by their companies to work on the C++ committee and on various compiler teams. The author of the post we're discussing is a member of the committee and this article is an attempt to improve the security situation in C++.

The people working on the C++ committee are mostly working on their own time. Specific project directly funded by companies are actually quite rare. And those mostly focus on companies very immediate needs.

If someone wanted to commit let's say 25$ million over 5 years, i am sure that both C++ standards and the major implementations would make large jump in term of safety.

> The issue is that the committee has a firm commitment to never introducing breaking changes. This commitment is so firm that it trumps literally any other interest, like making the language memory safe.

Yes C++ and its committee have very strong commitment to backward compatibility. However, that's not the reason for not wanting to make C++ memory safe : from what i understand, the committee decided that the tradeoff are not worth the gain, and as Hurb explain in this article, between tooling and reasonable default, it possible to achieve pretty good level of safety in practice.

> That's why the author only suggests non-breaking changes in this article.

Just to repeat my point here: no, Hurb is suggesting non-breaking changes because of the aforementioned commitment to back-compat. Even if breaking changes were to be introduces, they would most likely NOT be to make C++ a memory safe language whole sale

> as Hurb explain in this article, between tooling and reasonable default, it possible to achieve pretty good level of safety in practice.

This is the main contention. For those who believe in the technical leadership of the committee, this feels like a reasonable way forward.

I'm sure in theory these issues can be tackled, it's just that in practice the C++ community has always chosen performance over any other concern (https://research.swtch.com/ub). In that context, where you can change the APIs but you can't change how a whole community behaves, these articles by Sutter and Stroustrup feel like a Hail Mary play to address the valid concerns raised by multiple organisations around memory safety. I think we'll find out in 5 years if their optimism was well founded.

> it's just that in practice the C++ community has always chosen performance over any other concern (https://research.swtch.com/ub).

I don't know how much credence to give to this idea. It seems to me this specific this critic always comes from (designer of) languages with very different goal in mind.

If you ask a die hard C fan, they will point to things like exceptions handling, constructor and even type conversion as example where C++ is not making design decision purely on performance. It seems that from it's inceptions, modelisation power and type safety where paramount to C++ and it's design, right along performance.

In particular here, it hard for me not to read simply in the article you linked that the authors doesn't like the compromise that the C++ committee has chosen... Notthing really objective.

> you can't change how a whole community behaves, these articles by Sutter and Stroustrup feel like a Hail Mary play to address the valid concerns raised by multiple organisations around memory safety.

Maybe i have a different read of the situation. But we are talking about the same community which produced C++11, introducing both a memory model, thread semantic and lambda functions. And since then have produce pretty significant advance in the language every 3 years. The C++ community is more deliberate in its approach to solving issues, taking longer to make sure that the proposed solution actually address the correct problem.

> I think we'll find out in 5 years if their optimism was well founded.

True.

> That's why the author only suggests non-breaking changes in this article.

One of the proposals in the article is to change the meaning of things like "if (a != b > c)" and "if (0 <= index < max)". That changes program behavior and therefore is a breaking change (for instance, the code might accidentally be depending on the "wrong" results of these odd comparisons, and "fixing" them makes it go through an untested path which does the wrong thing).

It's ok if the current behaviour is changed into a compiler error

I agree; while changing it into a compiler error could be considered "breaking" (it no longer compiles), it's not a silent break and forces the developer to fix the code. (I would only worry about developers doing the "obvious" fix to shut the compiler up without looking at the surrounding code to see if it was masking some other bug.)

That feels imprecise to the point of rendering the entire conversation useless. If every major C++ compiler shipped a copy of `rustc` renamed to `g++` or `clang++` or whatever, that would also make every breaking change a compiler error, but I don't think that's what anybody is talking about here.

On the contrary, it's the absurd claim that making "if (a != b > c)" a compiler error is somehow remotely comparable to changing C++ syntax so that it's the same language as Rust is what renders the entire conversation useless and is not what anybody is talking about here.

> On the contrary, it's the absurd claim that making "if (a != b > c)" a compiler error is somehow remotely comparable to changing C++ syntax so that it's the same language as Rust is what renders the entire conversation useless and is not what anybody is talking about here.

My point is that "it's okay to turn something into a compiler error" is vague and I don't know where the line is actually drawn. I don't think the boundary between acceptable and unacceptable breakage is obvious, which is why I explicitly gave an example that I knew for sure was outside it. I don't think the idea that reasonable people might disagree about what level of breakage is acceptable particularly radical, so I think it's worth not immediately assuming I'm participating in bad faith.

This is the sort of ideological thinking that holds back progress and it's something people have complained about in particular with the C++ standardization process.

You always have these purists who think that because a solution doesn't solve the problem for every single use case, that we can't put forth solutions that solve the problem for 90% of use cases. The entire article that Herb Sutter is writing is really a push to fix the 90% of safety problems in C++ without coming up with an ideologically pure solution that tries to solve all of C++'s safety problems.

If someone puts forth a proposal that a fairly awkward and easily misunderstood and error prone expression like "bool > bool" should produce a compiler error, and your response is that if we do that, we may as well just change all of C++'s syntax so that one could rename rustc to g++ and it just works, then you are participating in bad faith as opposed to presenting a sensible argument that reasonable people can actually discuss and make some kind of meaningful progress.

> If someone puts forth a proposal that a fairly awkward and easily misunderstood and error prone expression like "bool > bool" should produce a compiler error, and your response is that if we do that, we may as well just change all of C++'s syntax so that one could rename rustc to g++ and it just work

My first comment gave and example followed by saying "I don't think that's what anyone here is talking about", and my most recent response reiterated that I considered my example as explicitly being outside the boundary of what anyone would consider acceptable. It feels like you're going through great lengths to try to present it as something I actually recommended when I've been quite clear that I don't think it's anywhere close to reasonable. I've been quite clear that I'm not proposing anything; on the contrary, I'm _asking_ about how to decide whether something is a breaking change that's worth it or not because I'm not at all an expert in C++ and I don't pretend to be.

The only "ideological thinking that holds back progress" due from "purists" going on here is your insistence that I should be disqualified from asking questions because I happened to try to use a hypothetical example that you didn't like.

Why would you go from the proposal in the article that involved making a confusing expression like "bool > bool" a compiler error, to the absurd example of suggesting that C++'s syntax be changed to be identical to Rust?

How could talking that way possibly be conducive to having a serious discussion about the article, which is trying to eliminate 90% of the safety issues in C++?

If that is the manner in which you think a reasonable discussion can be had on this issue, then no, you are no qualified to discuss it and your participation has done nothing and continues to do nothing but derail the topic which is likely why no one has bothered responding to you.

that's how you get companies to stop upgrading and eventually end up sitting on a 20 y/o version of C++.

2nd and 3rd order thinking is a thing.

If a company won't update because it really needs to depend on whether one bool compares greater to another then by all means they can stick to using 20 year old version of C++.

Other companies with modern engineering disciplines that don't write hacky code like that can benefit from a sane and sensible compiler instead of being dragged down.

If you can't understand how the expense of doing that may be onerous on a business then you shouldn't be let anywhere near decision making.

Too late for that, I am in a decision making position at a quant firm with very strict engineering standards and I absolutely stand by my decision that businesses that write code that compares booleans together like that should not be in a position to hold back other businesses that don't.

They can continue using 20 year old compilers and quit making the language worse for the rest of us who have put in the effort and cost of writing modern software.

It's always easy to make a decision when you're not the one paying the cost for it, or don't imagine you will be.

In fact, one of the red flags for decision makers is the inability to understand the above tenet.

I agree, asking everyone else to pay the cost of writing error prone code because they refuse to adapt but yet feel entitled to use new compilers is a big red flag and poor technical decision making that offloads the cost on the rest of the community.

I'm glad we managed to get that out of the way.

Companies that wish to stick with their existing and deprecated coding standards can stick to their existing and deprecated compilers, allowing those of is who wish to have safe and modern tools the freedom to make progress without their baggage holding us back.

oh snap guys, do you see what he did there in his parley? The way he took my point and pretended I was saying something else and that I really agreed with him. That technique so got me that he won!

This is most definitely the paragon that should be helping us decide which large swathe of people to fuck over.

The example given here is a different interpretation of a statement.

The source would stay the same for correct and incorrect use,there is no way for the compiler to catch this and send an error message.

It's certainly possible to make an expression of the form "bool > bool" a compiler error and require that developers rewrite it as "x && !y"

But they do break stuff.

I think the commitment is more that you can’t do anything to the language that would lead to some compiler hacker who also serves on the committee to have to remove their pet optimization, regardless of whether that optimization is worth much (or anything).

Goals and messaging matter. I like that the Rust community aims for safety as a P1 goal. C doesn’t, so C doesn’t get it.

> I don't know about this. There are a lot of people being paid by their companies to work on the C++ committee and on various compiler teams.

The standards document isn't the same as a C++ implementation. The implementations are actually behind the standards, at least given current contribution levels.

There are relatively few people making significant contributions to C and C++ in compilers. Funding for middle and backend features to compilers are a lot easier to justify and fund because it looks like more straightforward optimization payoffs.

A lot of the effort put into C++ implementation work goes to keeping up with the pile of features added to the C and C++ standards every three years or so.

His 98% figure sounds about right, doesn’t it? Eliminate 98% of C++ CVEs and that’s enough to compete with memory safe languages.

Is aiming for exact parity the best way to achieve that though? I'm skeptical that memory safe languages have 98% fewer CVES than C++ because their goal wass "have 2% of the CVEs that C++ has" and they succeeded and not "try to have no CVEs whatsoever" and they failed by a small amount.

The most recent data I could find, from 2019, shows that 17% of CVEs are in PHP code, 12% in Java, and 11% in JavaScript - all memory-safe languages.

Memory safety bugs are only one class of security vulnerabilities, and there's nothing magical about memory safeness that causes a developer using that language to suddenly become expert at writing secure code.

For that matter, some vulnerabilities actually seem much more common in memory-safe languages - try searching the CVE database for "SQL injection c++" (287 results) vs javascript (3420), Java (2160), or PHP (11300).

Except the CVEs in Rust are far more likely to be low severity issues that C++ would never acknowledge to begin with.

It would still be worthwhile to greatly reduce the number of vulnerabilities coming out of new C and C++ code, which are likely to be with us for a long time still. At the very least as updates/fixes to existing codebases.

Yes, no doubt - reducing the number of vulnerabilities is a good thing. What I'm worried about is that they merely reduce the number of CVEs, and call it a win for their safety initiative. It becomes a PR exercise more than technological improvement.

Well, pay attention and hold them accountable.

But Microsoft (for instance) certainly has incentives to avoid being the next Boeing or Volkswagen with respect to being excellent box checkers that end up missing the mark on the outcomes those checkboxes are supposed to protect against. It doesn't matter if C and C++ have fewer CVEs as such if Microsoft tools and platforms gain a reputation as being insecure or unsafe.

Sounds about right because he is using the number of eliminated CVEs, not the number of remaining CVEs. Compare with 98% and 99.8%; even when we have been tracking all possible CVEs, 98% elimination will leave 10x remaining CVEs than 99.8% elimination. (Of course both are much better than 0% elimination, i.e. status quo.) I feel the true figure would be somewhere around 99.8% and 99.98%, especially when a massive undercount from existing C/C++ projects is accounted for.

He addresses this point in the article as well, discussing risks that that language community gets too fixated on one kind of safety while attackers shift to other concerns like supply chain, code injection, or leaked credentials.

That sounds like a situation I'd describe as "a good problem to have". Almost completely eliminating a comment attack vector and having to figure out how to pivot to stamp out another type is far better than just not making any significant progress at all. If the concern were that they were already making progress on some of those other security concerns and they were worried that switching focus would risk gains they expect to make soon in those areas, I think that would be reasonable, but that doesn't seem to be the case. Is there any evidence that this concern is anything other than hypothetical? It comes across more as an attempt to justify not spending effort improving memory safety rather than something that anyone is actually concerned about.

Of course, but memory unsafety is one of the biggest enabler for security vulnerabilities. Attackers have shifted to other concerns when PHP became widespread enough for example, but PHP alone cannot be used to create a vulnerability common in C/C++ because of its memory safety (which is not even that good!), you need some other systems to combine multiple issues into a single coherent attack, and it's likely that C/C++'s memory unsafety has played a great role somewhere in between. He doesn't fully acknowledge this multiplicative aspect of memory (un)safety.

That seems far fetched to me. The vast majority of zero-days are still memory safety issues, and it would be an absolute miracle if the C++ community can get that ship turned around in under 20 years. Even 50 seems unreasonable honestly.

But how do you know that the language has eliminated 98% of vulnerabilities?

98% of what? CVEs? Something else?

Absolutely not. Software that has 98% fewer memory safety issues is…still exploited. People just look harder and the costs go up a bit.

No, there is in fact a qualitative difference between a program where the expected number of CVEs is 1, and one where the expected number of CVEs is 0.02.

Yes, there are fewer CVEs. So?

Are you being purposely dense?

If the mean number of CVEs is low enough, some proportion of software has 0 exploitable flaws, and is invulnerable regardless of how much attackers spend.

I consider that most software that people use is sufficiently complex enough that it will not fall in this bucket.

What if you normalize for the amount of code in the wild? Relatively little software I use day to day have significant amounts of rust in them (only Firefox and my phone OS, probably...). Even in firefox, there is far more C++ than rust...

You’d also have to define what “use” means. Your traffic that goes through Cloudflare hits Rust code: does that count as a “use”? Sites you use that rely on AWS almost certainly hits Rust code, does that count as a “use”?

I think it’s kind of stretching it, but these are services where issues in them could impact you, so I don’t think it’s a total non sequitur.

This is true - and also misses one of the points Herb Sutter's article is making. I don't disagree at all with what seems the general sentiment here about the importance of memory safety. I also, though, don't disagree with Herb Sutter that there are other safety-relevant aspects in both programming and software deployment which aren't helped/prevented "merely" by using memsafe languages.

Say, the "typical" rust laziness ... just unwrap() because well we know for sure it can't possibly be None, right ? Do that in a form of crit code path, and while that may not open you to an exploit, it'll still down your service and damn you to a crashloop.

Yes, we should be using memsafe languages. Yes, we should be a little humble about bugs we may create. As important as it is to entirely eliminate one "critical" class, as important it is to realize even with that gone, bugs/issues/security problems will remain.

> As important as it is to entirely eliminate one "critical" class, as important it is to realize even with that gone, bugs/issues/security problems will remain.

Sure. Nobody believes that memory safety is the sole security issue. Or at least, no serious people, or any of the organizations doing advocacy around this issue.

And just to be clear, in C++ a "bad unwrap" could become an exploitable gadget in arbitrary code execution or bypassing security checks or literally any really serious issue. Also, the same issue would show up as any one of N failures and may even be missed.

In Rust it would manifest as a DOS attack vector and the issue would be blamed to the bad unwrap 100% of the time.

So the C++ case the possible failure modes are arbitrarily serious vulnerability with poor observability and difficulty finding it. In Rust that failure mode is a mild generally non-exploitable vulnerability* that 100% of the time fails in the exact same way making monitoring & detection trivial.

* Yes, it could be a single stage of an exploit where you take down 1 service which opens up another vulnerability. But that's still a more expensive exploit (in terms of $ to discover) than if you had this problem in C++.

> Say, the "typical" rust laziness ... just unwrap() because well we know for sure it can't possibly be None, right ?

Which is safe.

> Do that in a form of crit code path, and while that may not open you to an exploit,

Oh, so you realize that it is safe.

> it'll still down your service and damn you to a crashloop.

So there isn’t an argument here.

Next.

"memory-safe" != "safe".

Make a fair assessment what it means to your app / service when you have a, however controlled/contained, reproducible unexpected (by the developer) exit. Or what it means to use a hardcoded default (unwrap_or). Or what it means to pass up an Err via "?". Or to map an Err to None.

My argument is simple: The memory safety of rust is no reason to become arrogant as a programmer. It should, in fact, maybe make you more humble - what you learned about your own typical mistakes as you learned to write rust and tackle the borrow checker and decode clippy's extensive litany of sins in your source. And to consider that rust, as prime example, exists because people learned - from mistakes. From those design flaws in C/C++, namely.

Assume you make mistakes as well is likely to turn you into a better person. Definitely into a better programmer. No matter which language you use. Hopefully rust (on that I fully agree)

I will try to be more humble. Thank you.

A DOS attack is still a security vulnerability, but as I describe above it's still a better failure mode than you get with C++.

> it'll still down your service and damn you to a crashloop.

Nope. Your service will be structured such that it is subdivided in tasks, each task being wrapped in a `catch_unwind`[1], such that a panic merely kills the task it occurs in, not your service.

[1]: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

that's totally fair, certainly there are web servers I use that are probably using rust somewhere, but I suspect it's still a relatively small amount of code (even if widely used!).

> Take for example CVE-2022-21658 (https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html) in Rust, related to a filesystem API. It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all.

That just plain wrong. Just simply wrong. And I hope it is not a lie done on purpose.

The C++ community acknowledge the issue as soon as the Rust one posted the problem and issued a fix which is already deployed with major compilers [^1] [^2]

It does not have a CVE associated since the issue was spotted within Rust stdlib first.

This is this exact kind of FUD and zealotism that makes people hate the Rust community. I wish the community mature a bit on this aspect.

[^1]: https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d...

[^2]: https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9...

> It does not have a CVE associated since the issue was spotted within Rust stdlib first.

I don't see why this is true. Are you saying that people with affected code would have seen a Rust CVE and then updated their C++ toolchains? There seems to be no reason this shouldn't have been a C++ CVE other than the fact that C++ community has different standards for what constitutes safety. The lack of CVE associated with the fixes you pointed out support the original assertion rather than refuting it.

In fact, I'll tell you why there was no CVE for C++ - concurrent access to filesystem APIs is undefined behaviour in C++ (https://en.cppreference.com/w/cpp/filesystem).

Reasonable people can disagree on this though, so I can see where you're coming from. There's no reason to immediately fling around accusations of lying and zealotry. It makes the writer look immature.

how would you define concurrent access to a filesystem?

That's a serious question, if I open a file for reading and another process writes to it, exactly how is the C++ standards supposed to protect against that?

> There seems to be no reason this shouldn't have been a C++ CVE other than the fact that C++ community has different standards for what constitutes safety

A security report has been filed for both compiler and actions taken for both of the major toolchain. This is a sign of mature security processes in used by both of the major C++ compiler implementations.

CVE are one among many way to address security vulnerabilities, one way that is currently heavily under criticism [^1]

> In fact, I'll tell you why there was no CVE for C++ - concurrent access to filesystem APIs is undefined behaviour in C++

The vulnerability reported (even in case of the Rust CVE) has nothing to do with a concurrent usage of the API. I think you do not really know what you are talking about here.

> Reasonable people can disagree on this though, so I can see where you're coming from. There's no reason to immediately fling around accusations of lying and zealotry. It makes the writer look immature.

My definition of immature includes the fact of throwing false statement over the internet, getting them refuted with sources and quote included. And still stance on them. This is a sign of immaturity.

[^1]: https://portswigger.net/daily-swig/cvss-system-criticized-fo...

The issue entirely hits that undefined behaviour. The problem is a race condition in symlinks -- a race condition implies a change, which is concurrent access, and the C++ standard clearly states any change to the filesystem by another program leads to undefined behaviour.

Sure, the "concurrent access" is another program, but the standard says another program changing an object you are accessing leads to undefined behaviour -- which does make, writing basically any C++ program that does filesystem access on a modern OS with other programs running completely impossible according to the letter of the standard, so I'm really not sure why it's written in that way.

No it isn't, it's just a bug and it was fixed, just like it was for Rust. Nobody hid behind UB for this and the time from reporting the issue to fixing it was about 2 weeks for both libcxx and libc++

https://bugs.chromium.org/p/llvm/issues/detail?id=19

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104161

Absolutely zero mention or attempted defense of "hurr durr but UB says we can do this!!!"

C++ is the standard. Not the implementations. The bug is fixed in the implementations, but remains in C++.

Where is the bug in the C++ standard? std::remove_all states:

> 1,2) The file or empty directory identified by the path p is deleted as if by the POSIX remove. Symlinks are not followed (symlink is removed, not its target). > 3,4) Deletes the contents of p (if it is a directory) and the contents of all its subdirectories, recursively, then deletes p itself as if by repeatedly applying the POSIX remove. Symlinks are not followed (symlink is removed, not its target).

Nowhere in there does it say "lol but FUCK YOU if you're on a multiprocessing system lololololol" or anything remotely close to that.

> 29.11.2.3 File system race behavior [fs.race.behavior]

> 1 A file system race is the condition that occurs when multiple threads, processes, or computers interleave access and modification of the same object within a file system. Behavior is undefined if calls to functions provided by subclause [fs.race.behavior] introduce a file system race.

> 2 If the possibility of a file system race would make it unreliable for a program to test for a precondition before calling a function described herein, Preconditions: is not specified for the function. [ Note: As a design practice, preconditions are not specified when it is unreasonable for a program to detect them prior to calling the function. — end note ]

There you go. "Behavior is undefined" is essentially "fuck you, you won't get any error you'll just get garbage at runtime". It does thankfully allow the implementations to make it an error at runtime (as they did), but does not require it, so the standard still has the bug.

The answer to that is there: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n40...

It is mainly wording around specifying that the result of a concurrent access can not be guaranteed. Which here Rust is no different, it just does not have a specification for his stdlib (yet)

I disagree, while rust doesn't have a formal specification, they would consider any crashes in safe code caused by parallel filesystem access to be unacceptable, while for years the C++ committee has been happy to say "You fool, you invoked undefined behaviour. Game over". I don't see any evidence from looking at the standard this bit of undefined behaviour is somehow "less undefined" than any other bit of undefined behaviour.

> I think you do not really know what you are talking about here.

Yeah, maybe.

The reference says

> The behavior is undefined if the calls to functions in this library introduce a file system race, that is, when multiple threads, processes, or computers interleave access and modification to the same object in a file system.

My understanding of the vulnerability happens because a different process interleaves access to the same object in the file system between the time of check (TOC) and time of use (TOU) leading to the TOCTOU bug. And this isn't a vulnerability in C++ because it's considered UB by the spec.

I'd be really interested in hearing you explain why this section of the spec isn't relevant to the TOCTOU bug. I'd learn something new if that's the case.

I know you're frustrated by the discussion of CVEs but please understand that the entire article and this thread is based on understanding C and C++'s security record based on CVEs. Herb Sutter compared C++ with Rust, pointing out 61 CVEs in C++ and 6 in Rust. Therefore it's really relevant to compare the attitudes of both communities about filing those CVEs. The fact that the exact same vulnerability warranted a Rust CVE but not a C++ CVE is quite telling.

I'm not happy with the CVE system, no one is. You're not either. All I'm saying is, comparisons of CVEs across languages, like Sutter has done, aren't helpful or useful. He claims that C++ will be equally safe as Rust if CVEs were reduced by 90%. But as long as the C++ community doesn't file CVEs when Rust does, that's not correct. And it's likely to be more incorrect if the community follows through with Herb's suggestion to take control of the CVE filing mechanism.

> My understanding of the vulnerability happens because a different process interleaves access to the same object in the file system between the time of check (TOC) and time of use (TOU) leading to the TOCTOU bug. And this isn't a vulnerability in C++ because it's considered UB by the spec.

The definition as Undefined Behaviour in the spec is quite unfortunate and a mistake. We do agree on that.

> I'm not happy with the CVE system, no one is. You're not either. All I'm saying is, comparisons of CVEs across languages, like Sutter has done, aren't helpful or useful.

On this I do agree too. And saying that a lot of communities have things to learn from the Rust core team about security issue handling is a completely fair statement.

What infuriated me was your point:

> but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed

Which tend to under-mean that the C++ community took no action regarding to this exact problem. When, in fact, it is already patched and released in all major implementations (exactly like Rust did).

Yeah you're right, I originally said no action was taken because I was going off of my recollection of the original issue 2 years ago. When Rust released this blog post (Jan 20th 2022) the same issue had been fixed already in Python. When I asked around about C++, people pasted the reference link and said it didn't need to be fixed because it was defined as UB. I stand corrected, they did fix it. And good on them for fixing it and not closing it as "spec says its fine".

It's still bad they didn't file a CVE for it, knowing that other languages did so. It reduces trust in their ecosystem.

> It's still bad they didn't file a CVE for it, knowing that other languages did so. It reduces trust in their ecosystem.

Curiosity question: Do you know if python has also a CVE for this exact same problem ? I am not able to find it back through their git history.

In my understanding, no. I believe it was bpo-4489 [1], and I couldn't find a matching advisory from the PSF's database [2] which should contain most historical advisories as well (it does seem to miss earliest advisories like PSF-2005-001 and PSF-2006-001 though).

[1] https://github.com/python/cpython/issues/48739

[2] https://github.com/psf/advisory-database/

I was pointed multiple times by people to the C++ standard, which clearly states (when introducing the filesystem library):

"The behavior is undefined if the calls to functions in this library introduce a file system race, that is, when multiple threads, processes, or computers interleave access and modification to the same object in a file system."

and was told that made this bug not a compiler issues, but just undefined behaviour, exactly as if you'd written an array out of bounds or dereferenced an invalid pointer, the compiler can do anything it likes if another program changes the filesystem while your program runs.

There is a lot to bet that this has been added for portability reasons. The POSIX atomicity guarantees on file operations are not provided on every system.

The facts are, when this issue came, it has been treated as it should have been. This is, once again, a sign of mature security processes and behaviour regarding the compiler implementers.

> It does not have a CVE associated since the issue was spotted within Rust stdlib first.

That is blatant nonsense. Even if the vulnerability is similar or identical, CVEs are submitted for every affected project. If it were not there would not have been a bounds-check CVE in the last 35 years. The only situation in which that might not be the case is if the vulnerability is in an upstream library, but even then you often get a CVE in both upstream and downstream (or a CVE shared between multiple products) e.g. the libwebp 0-day from late 2023 got a CVE for Apple’s various OS (two in fact) and a shared CVE for libwebp and chrome, mozilla used that as their upstream CVE in emitting a security advisory.

The CVE-2022-21658 only covers the Rust standard library, that is not upstream of either libc++ or libstdc++, and neither fix references it anyway.

The GP might have gone a hair too far in saying that C++ “does not consider it a problem at all”, but they’re correct that C++ compiler/stdlib maintainers do not consider it a vulnerability.

> The GP might have gone a hair too far in saying that C++ “does not consider it a problem at all”, but they’re correct that C++ compiler/stdlib maintainers do not consider it a vulnerability.

No this is also just plain wrong.

It was reported to both compiler through channels dedicated to report security vulnerabilities and has been fixed as such.

The fact it did not make his way through a CVE is mainly related to how CVE naming and reservation works, nothing more.

> The fact it did not make his way through a CVE is mainly related to how CVE naming and reservation works, nothing more.

Still.. that little detail makes comparing the numbers of CVEs for Rust and C++ skewed by an enormous amount.

Reply on news.ycombinator.com