2 ms·

There have been twelve CVEs reported against coreutils in the past twenty years. There were forty-four against this project in just the last audit. I am all f

by stouset 12d ago

There have been twelve CVEs reported against coreutils in the past twenty years. There were forty-four against this project in just the last audit. I am all for RIIR in cases where it makes sense. This does not even remotely appear to be one of them. By all appearances the quality of the code is extremely amateurish at best. coreutils has not been a significant source of vulnerabilities in the past, and they’re replacing it with code written by amateurs that performs worse and already has a worse security track record.

Ygg2 12d ago
> There were forty-four against this project in just the last audit. Was there an audit against coreutils? If not, it's not really apple-to-apple comparison.
- stouset 12d ago
  It doesn’t even matter. The sheer disparity in vulnerabilities over twenty years versus one year is impossible to hand-wave away. We are talking about fourfold more CVEs over a twentyfold reduction in time.
  - gpm 12d ago
    It really does matter. I don't know enough about this specific case, but multiple order of magnitude differences in CVE numbers are frequently explained by different policies towards finding and assigning CVEs in many many cases. Absent more information the default should be to hand wave it away as probably such a difference. CVE counts are not a even slightly reliable metric.
    - collinfunk 12d ago
      Most of them are TOCTOU races or improperly following symbolic links. For example, uutils mkfifo(1) would create a world-readable and writable FIFO before using chmod(2) to restrict its permissions. Another user could replace that file with a symbolic link between the mkfifo(3) call and the chmod(2) to change the permissions of arbitrary files [1]. Other ones I find concerning are that you could also bypass '-- no-preserve-root' with a symbolic link to root [2]. Or by using paths equivalent to "/", e.g., "/../" [3]. Historically, GNU coreutils has been pretty good with symbolic links and avoiding TOCTOU races. The only notable one I can remember is a chmod(1) bug [4]. I agree with your general point that the number of CVEs is a useless metric, though. [1] https://nvd.nist.gov/vuln/detail/cve-2026-35352 https://nvd.nist.gov/vuln/detail/cve-2026-35352 [2] https://nvd.nist.gov/vuln/detail/cve-2026-35349 https://nvd.nist.gov/vuln/detail/cve-2026-35349 [3] https://nvd.nist.gov/vuln/detail/cve-2026-35338 https://nvd.nist.gov/vuln/detail/cve-2026-35338 [4] https://github.com/coreutils/coreutils/commit/425b8a2f534fe02e8c1e39ad6a3d2c18eca12de3 https://github.com/coreutils/coreutils/commit/425b8a2f534fe0...

by stouset 12d ago

Ygg2 12d ago

> There were forty-four against this project in just the last audit. Was there an audit against coreutils? If not, it's not really apple-to-apple comparison.

stouset 12d ago
It doesn’t even matter. The sheer disparity in vulnerabilities over twenty years versus one year is impossible to hand-wave away. We are talking about fourfold more CVEs over a twentyfold reduction in time.
- gpm 12d ago
  It really does matter. I don't know enough about this specific case, but multiple order of magnitude differences in CVE numbers are frequently explained by different policies towards finding and assigning CVEs in many many cases. Absent more information the default should be to hand wave it away as probably such a difference. CVE counts are not a even slightly reliable metric.
  - collinfunk 12d ago
    Most of them are TOCTOU races or improperly following symbolic links. For example, uutils mkfifo(1) would create a world-readable and writable FIFO before using chmod(2) to restrict its permissions. Another user could replace that file with a symbolic link between the mkfifo(3) call and the chmod(2) to change the permissions of arbitrary files [1]. Other ones I find concerning are that you could also bypass '-- no-preserve-root' with a symbolic link to root [2]. Or by using paths equivalent to "/", e.g., "/../" [3]. Historically, GNU coreutils has been pretty good with symbolic links and avoiding TOCTOU races. The only notable one I can remember is a chmod(1) bug [4]. I agree with your general point that the number of CVEs is a useless metric, though. [1] https://nvd.nist.gov/vuln/detail/cve-2026-35352 https://nvd.nist.gov/vuln/detail/cve-2026-35352 [2] https://nvd.nist.gov/vuln/detail/cve-2026-35349 https://nvd.nist.gov/vuln/detail/cve-2026-35349 [3] https://nvd.nist.gov/vuln/detail/cve-2026-35338 https://nvd.nist.gov/vuln/detail/cve-2026-35338 [4] https://github.com/coreutils/coreutils/commit/425b8a2f534fe02e8c1e39ad6a3d2c18eca12de3 https://github.com/coreutils/coreutils/commit/425b8a2f534fe0...