← Back to context

Comment by Orygin

3 hours ago

How many CVEs in coreutils over the years? The project has the advantage of being old enough for them to be fixed. Call me when the rust rewrite has been there that long and still has more CVEs than the GNU counterpart.

Not sure how reliable this site is, but if it is correct it looks like 10: https://www.cvedetails.com/vulnerability-list/vendor_id-72/p....

Maybe coreutils is so old that most security vulnerabilities was solved before CVE even existed. But I think this is also a good argument why we are replacing a solid piece of C code to Rust just because it is "memory safe" and then have lots of CVEs related to things like TOCTOUs (that Rust will not save you).

  • I'm not against rewriting it in Rust because I believe it really may help in certain class of bugs, but indeed it should not be replacing the old version instantly for that reason. Both could co exist, even tho you still need some guinea pigs to test it out and find issues

  • People thinking that using a superior tool (on paper) enables them to automatically write better tools than the ones who are battle tested over the years baffles me to no end.

    Yes, you can go further, possibly faster. OTOH, nothing replaces experience and in-depth knowledge. GNU Coreutils embodies that knowledge and experience. uutils has none, and just tries to distill it with tests against the GNU one.

    ...and they get 44 CVEs as a result in their first test.

    • There was an article posted to HN recently that enumerated bugs in the rust rewrite.

      Iirc the bugs had to do with linux system details like fs toctou and other things you'd only find out about in production.

      Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs, so that every project doesn't have to relearn them at runtime. But the rewrite isn't pure downside.

      1 reply →