| ▲ | throwa356262 2 days ago |
| That was a lot of CVEs Goes to show that not all security bugs are memory related bugs |
|
| ▲ | sph 2 days ago | parent | next [-] |
| Not aimed at you but... no sh*t. The "Rewrite it in Rust" community never heard of the second-system effect. I'd rather use something written in a crappier language that has been battle-tested for decades, personally. |
| |
| ▲ | yjftsjthsd-h 2 days ago | parent | next [-] | | > I'd rather use something written in a crappier language that has been battle-tested for decades, personally. I don't think this is a universal rule. Something can be old but still suck (see: openssl). On the flip side, though, I'd like to see literally any evidence that coreutils has a security problem before we go jumping off onto the shiny new replacement. | |
| ▲ | perching_aix 2 days ago | parent | prev | next [-] | | I see this accusation and characterization in basically every thread about Rust, but I really don't think it's true. On the contrary, I strongly believe it's less that these people didn't consider that, and more that they willfully chose to ignore it. If you always keep praying to the same old bit of code to "reliably" chug along (which people clearly cannot actually ascertain, otherwise these reimplementations wouldn't be struggling), you're forever just rolling the dice that some Pandora's box will simply never open (which it absolutely does and keeps opening), while also giving up on modern capabilities. What you see as old reliable, I see as a buried lede. I'd imagine these folks see the same. [0] It's frustrating to see the software world contend with the same pushback and counter-arguments the infra/ops world (my neck of the woods) has already figured out and went past long ago during the advent of IaC. Cattle > pets, easily, every time. [0] It's also not a cost-benefit thing, but clearly a principled decision, so arguments that aim to contend the ROI of it all are off-base from the get-go. If ROI is the key thing for you, then all this philosophical nonsense shouldn't even be on the table. Calculate. | |
| ▲ | mamcx a day ago | parent | prev | next [-] | | That is a bad take, because that imply "crappier language will be used for MORE decades". Rust is an absolute improvement over C/C++ in major ways. Once there, for ALL THAT DECADES all the developers and all the code written will be spared the problems of "crappier languages. In the short term there are adaptation issues? fine. But that will be erased (way faster than is possible with C) and suddenly, never again worry about things. | |
| ▲ | illiac786 2 days ago | parent | prev [-] | | “battle tested for decades” just lost a lot of its value with Mythos and the likes unfortunately. Rewriting in a different language became much faster with Coding agents at the same time. I do agree that the second system effect is real, it’s just that the balance of benefits and drawbacks significantly shifted when it comes to “rewrite in Rust” (not limited to Rust though). | | |
| ▲ | sph 2 days ago | parent | next [-] | | > “battle tested for decades” just lost a lot of its value with Mythos and the likes unfortunately Isn't it a bit early to make predictions on the future of computer security and how we create good software based on something that's been out for 2 weeks? Meanwhile the C version of coreutils has been in development for 36 years. There's no rush. | |
| ▲ | 2 days ago | parent | prev | next [-] | | [deleted] | |
| ▲ | LtWorf 2 days ago | parent | prev [-] | | Yay we can create new CVEs faster! |
|
|
|
| ▲ | IshKebab 2 days ago | parent | prev | next [-] |
| I wish they'd put the severity. There are 4 highs, the rest are medium or low. Here are the high ones: https://www.cve.org/CVERecord?id=CVE-2026-35338 - `chmod --preserve-root` can be bypassed. That doesn't seem that bad tbh. https://www.cve.org/CVERecord?id=CVE-2026-35341 - `mkfifo` accidentally resets the permissions of files that already exist, so if you manage to do `sudo mkfifo /etc/shadow` then it becomes world readable. https://www.cve.org/CVERecord?id=CVE-2026-35352 - TOCTOU in `mkfifo` lets you do the symlink trick to get it to change permissions on an unrelated file. https://www.cve.org/CVERecord?id=CVE-2026-35368 - You might be able to get chroot to execute arbitrary code. Tbh I doubt if any of these would ever result in a real hack, unless your system is doing really mental things like running shell scripts with untrusted input. I could only find a couple of CVEs that looked actually serious for GNU Coreutils too though. IMO if you're using these tools with untrusted input your system is janky enough that there are going to be serious flaws in it anyway. Probably though quoting mistakes. |
| |
| ▲ | sph 2 days ago | parent | next [-] | | I clicked a random one: https://www.cve.org/CVERecord?id=CVE-2026-35344 Quote from the CVE description: "The dd utility in uutils coreutils suppresses errors during file truncation [...] This can lead to silent data corruption in backup or migration scripts, as the utility may report a successful operation even when the destination file contains old or garbage data." That's terrifying. There's more to bugs than security bugs. You'd expect coreutils to be as bug-free as possible. | |
| ▲ | collinfunk 2 days ago | parent | prev [-] | | Well the TOCTOU issues do not require you to run untrusted scripts to be exploited. Another user on your system can use a legitimate command that you may run to make changes to files they shouldn’t be able to, or further escalate privileges. | | |
| ▲ | IshKebab 2 days ago | parent [-] | | Fair point. Though tbh I still think the user-isolation security for Linux is only really suited for the University/company threat model, where you generally trust users not to actually use exploits because they would get expelled/fired. If you allow a completely untrusted user onto your system I think your chances of staying secure are low. | | |
| ▲ | aragilar 2 days ago | parent [-] | | Then why rewrite coreutils in rust? TOCTOU isn't exact some new concept. Neither are https://owasp.org/Top10/2025/ (most of which a good web framework will prevent or migrate), and switching to rust (which as far as I know) won't bring you a safer web framework like django or rails. | | |
| ▲ | IshKebab 21 hours ago | parent [-] | | I don't know their motivations but mine would be: 1. Rust is a much more pleasant language to work with. 2. You can improve the tools, adding new features, fixing UX paper cuts etc. You're probably thinking "you can improve the GNU versions!" and in theory sure. But in practice these sorts of tools are controlled by naysayers who want everything to stay as it was in the 80s. The sorts of people that only accept patches via git send-email to a mailing list. Hahaha I just looked up GNU Coreutils and not only do they blame poor UX on the user ("Often these perceived bugs are simply due to wrong program usage.") but they even maintain a list of rejected feature requests: https://www.gnu.org/software/coreutils/rejected_requests.htm... And to nobody's surprise, to contribute it is git send-email to a mailing list. | | |
| ▲ | aragilar 4 hours ago | parent | next [-] | | Have you used busybox? The BSDs? I'm not sure adding more features to coreutils is a major help, and given rust-coreutils/uutils has: 1) more CVEs between two latest Ubuntu releases than coreutils has had over the last 30+ year 2) managed to break security updates 3) is neither fully compatible with POSIX nor coreutils I'm not sure why I'd ever use it? Sadly, projects like uutils have made me suspicious of rust projects, so unless I know that the project is well maintained (for which there are numerous examples, ripgrep being the obvious example, but newsboat, the various tools from proxmox, servo/firefox, and the pgrx ecosystem are ones I use regularly), it's a negative marker against that project. | |
| ▲ | collinfunk 16 hours ago | parent | prev [-] | | Another maintainer and I follow issues and pull requests on a GitHub mirror. But email works fine for us and many other projects. Regarding poor UX, it is difficult to dispute with that claim without a specific example. Note that a lot of the features we support are standardized by POSIX. Even if we dislike the behavior, it is better to comply with the standards so the programs don't behave differently than users expect. The sentence you quote isn't meant to put down users. These programs are often much more complex than meets the eye, and there are lots of common gotchas that people have run into (and will continue to do so) [1]. Of course we would love for these programs to be useful for everyone. However, feature requests are often incompatible with existing behavior, incompatible with other feature requests, or have existing functionality elsewhere. For those reasons we cannot accept every feature request. [1] https://www.pixelbeat.org/docs/coreutils-gotchas.html |
|
|
|
|
|
|
| ▲ | nine_k 2 days ago | parent | prev [-] |
| Indeed, many bugs are API usage bugs, something that no language can verify. (The API is implemented in C anyway.) |
| |
| ▲ | IshKebab 2 days ago | parent [-] | | No, but some languages make designing difficult-to-misuse APIs a lot easier than others. | | |
| ▲ | nine_k 2 days ago | parent [-] | | It's Linux, it's a C API, so there's little hope. I wonder if Redox has a much better API; at least I hope it does. |
|
|
