11 ms·

Bugs Rust won't catch

• wahern 5mo ago
  > What’s notable is that all of these bugs landed in a production Rust codebase, written by people who knew what they were doing They knew how to write Rust, but clearly weren't sufficiently experienced with Unix APIs, semantics, and pitfalls. Most of those mistakes are exceedingly amateur from the perspective of long-time GNU coreutils (or BSD or Solaris base) developers, issues that were identified and largely hashed out decades ago, notwithstanding the continued long tail of fixes--mostly just a trickle these days--to the old codebases.
  • AlotOfReading 5mo ago
    Someone once coined a related term, "disassembler rage". It's the idea that every mistake looks amateur when examined closely enough. Comes from people sitting in a disassembler and raging the high level programmers who had the gall to e.g. use conditionals instead of a switch statement inside a function call a hundred frames deep. We're looking solely at the few things they got wrong, and not the thousands of correct lines around them.
    • irishcoffee 5mo ago
      When I read the article I came away with the impression that shipping bugs this severe in a rewrite of utils used by hundreds of millions of people daily (hourly?) isn’t ok. I don’t think brushing the bad parts off with “most of the code was really good!” is a fair way to look at this. Cloudflare crashed a chunk of the internet with a rust app a month or so ago, deploying a bad config file iirc. Rust isn’t a panacea, it’s a programming language. It’s ok that it’s flawed, all languages are.
      • gmueckl 5mo ago
        I think that legitimate real world issues in rust code should be talked about more often. Right now the language enjoys a reputation that is essentiaöly misleading marketing. It isn't possible to create a programing language that doesn't allow bugs to happen (even with formal verification you can still prove correctness based on a wrong set of assumptions). This weird, kind of religious belief that rust leads to magically completely bug free programs needs to be countered and brought in touch with reality IMO.
        • testdelacc1 5mo ago
          Is it possible you’ve misunderstood what Rust promises? > It isn't possible to create a programing language that doesn't allow bugs to happen Yes, that’s true. No one doubts this. Except you seem to think that Rust promises no bugs at all? I don’t know where you got this impression from, but it is incorrect. Rust promises that certain kinds of bugs like use-after-free are much, much less likely. It eliminates some kinds of bugs, not all bugs altogether. It’s possible that you’ve read the claim on kinds of bugs, and misinterpreted it as all bugs. I’ve had this conversation before, and it usually ends like https://www.smbc-comics.com/comic/aaaah https://www.smbc-comics.com/comic/aaaah
          • adrian_b 5mo ago
            "Rust" obviously does not promise that. On the other hand, there are too many less-experienced Rust fans who do claim that "Rust" promises this and that any project that does not use Rust is doomed and that any of the existing decades-old software projects should be rewritten in Rust to decrease the chances that they may have bugs. What is described in TFA is not surprising at all, because it is exactly what has been predicted about this and other similar projects. Anyone who desires to rewrite in Rust any old project, should certainly do it. It will be at least a good learning experience and whenever an ancient project is rewritten from scratch, the current knowledge should enable the creation of something better than the original. Nonetheless, the rewriters should never claim that what they have just produced has currently less bugs than the original, because neither they nor Rust can guarantee this, but only a long experience with using the rewritten application. Such rewritten software packages should remain for years as optional alternatives to the originals. Any aggressive push to substitute the originals immediately is just stupid (and yes, I have seen people trying to promote this). Moreover, someone who proposes the substitution of something as basic as coreutils, must first present to the world the results of a huge set of correctness tests and performance benchmarks comparing the old package with the new package, before the substitution idea is even put forward.
            • testdelacc1 5mo ago
              Where are these rust fans? Are they in the room with us right now? You’ve constructed a strawman with no basis in reality. You know what actual Rust fans sound like? They sound like Matthias Endler, who wrote the article we’re discussing. Matthias hosts a popular podcast Rust in Production where talks with people about sharp edges and difficulties they experienced using Rust. A true Rust advocate like him writes articles titled “Bugs Rust Won’t Catch”. > Such rewritten software packages should remain for years as optional alternatives to the originals. This project was started a decade ago. (https://news.ycombinator.com/item?id=7882211 https://news.ycombinator.com/item?id=7882211) > must first present to the world the results of a huge set of correctness tests and performance benchmarks Yeah, you can see those in https://github.com/uutils/coreutils https://github.com/uutils/coreutils. This project has also worked with GNU coreutils maintainers to add more tests over time. Check out the graph where the total number of tests increases over time. > before the substitution idea is even put forward I partly agree. But notice that these CVEs come from a thorough security audit paid for by Canonical. Canonical is paying for it because they have a plan to substitute in the immediate future. Without a plan to substitute it’s hard to advocate for funding. Without funding it’s hard to find and fix these issues. With these issues unfixed it’s hard to plan to substitute. Chicken and egg problem. > less bugs Fewer.
      • lelanthran 5mo ago
        I find it hilarious that this comment is being downvoted. Exactly what is the controversial take here? > I don’t think brushing the bad parts off with “most of the code was really good!” is a fair way to look at this. Nope. this is fine. > Cloudflare crashed a chunk of the internet with a rust app a month or so ago, deploying a bad config file iirc. Maybe this? > Rust isn’t a panacea, it’s a programming language. It’s ok that it’s flawed, all languages are. Nope, this is fine too.
        • dbdr 5mo ago
          I didn't downvote, but I feel the last two points show a lack of nuance. It's saying "Rust doesn't prevent 100% of the bugs, like all other programming languages", while failing to acknowledge that if a programming language prevents entire classes of bugs, it's a very significant improvement.
          • adrian_b 5mo ago
            Nobody disputes that Rust is one of the programming languages that prevent several classes of frequent bugs, which is a valuable feature when compared with C/C++, even if that is a very low bar. What many do not accept among the claims of the Rust fans is that rewriting a mature and very big codebase from another language into Rust is likely to reduce the number of bugs of that codebase. For some buggier codebases, a rewrite in Rust or any other safer language may indeed help, but I agree with the opinion expressed by many other people that in most cases a rewrite from scratch is much more likely to have bugs, regardless in what programming language it is written. If someone has the time to do it, a rewrite is useful in most cases, but it should be expected that it will take a lot of time after the completion of the project until it will have as few bugs as mature projects.
            • kibwen 5mo ago
              As other people have mentioned, the goal of uutils was not "let's reduce bugs in coreutils by rewriting it in Rust", it was "it's 2013 and here's a pre-1.0 language that looks neat and claims to be a credible replacement for C, let's test that hypothesis by porting coreutils, giving us an excuse to learn and play with a new language in the process". It seems worth emphasizing that its creation was neither ideologically motivated nor part of some nefarious GPL-erasure scheme, it was just some people hacking on a codebase for fun. Whether or not it was wise for Canonical to attempt to then take that codebase and uplift it into Ubuntu is a different story altogether, but one that has no bearing on the motivations of the people behind the original port itself. You can see an alternative approach with the authors of sudo-rs. Rather than porting all of userspace to Rust for fun, they identified a single component of a particularly security-critical nature (sudo), and then further justified their rewrite by removing legacy features, thereby producing an overall simpler tool with less surface area to attack in the first place. It was not "we're going to rewrite sudo in Rust so it has fewer bugs", it was "we're going to rewrite sudo with the goal of having fewer bugs, and as one subcomponent of that, we're going to use Rust". And of course sudo-rs has had fresh bugs of its own, as any rewrite will. But the mere existence of bugs does not invalidate their hypothesis, which is that a conscientious rewrite of a tool can result in fewer bugs overall.
      • fluffybucktsnek 5mo ago
        If I'm not mistaken, in the Cloudflare case, both the Rust rewrite and the C++ original version crashed. The primary cause being the bad config file.
        • adrian_b 5mo ago
          Yes, but the point was that rewriting something in Rust is not sufficient per se to prevent such bugs. The goal claimed by all these rewrites is the elimination of bugs.
          • saghm 5mo ago
            The "elimination of bugs" is not synonymous with "the elimination of all bugs". The way you're presenting it, any single bug in a rewrite would be grounds to consider the the entire endeavor a failure, which is a ridiculous standard. There are plenty of strong arguments to be made against rewriting something in Rust, but this is a pretty weak one.
    • Cthulhu_ 5mo ago
      Thing is, these tools are so critical that even one error may cause systems to be compromised; rewriting them should never be taken lightly. (Actually ideally there's formal verification tools that can accurately test for all of the issues found in this review / audit, like the very timing specific path changes, but that's a codebase on its own)
      • bluGill 5mo ago
        Is formal verification able to find most of these issues? I'm no expert on formal analysis, but I suspect most systems are not able to handle many of these errors. It seems more likely that the system will assume the file doesn't change between two syscalls - which seems to be the majority of issues. Modeling that possibility at least makes the formal system much harder to make.
  • nine_k 5mo ago
    More than that: it seems that Rust stdlib nudges the developer towards using neat APIs at an incorrect level of abstraction, like path-based instead of handle-based file operations. I hope I'm wrong.
    • NobodyNada 5mo ago
      Nearly every available filesystem API in Rust's stdlib maps one-to-one with a Unix syscall (see Rust's std::fs module [0] for reference -- for example, the `File` struct is just a wrapper around a file descriptor, and its associated methods are essentially just the syscalls you can perform on file descriptors). The only exceptions are a few helper functions like `read_to_string` or `create_dir_all` that perform slightly higher-level operations. And, yeah, the Unix syscalls are very prone to mistakes like this. For example, Unix's `rename` syscall takes two paths as arguments; you can't rename a file by handle; and so Rust has a `rename` function that takes two paths rather than an associated function on a `File`. Rust exposes path-based APIs where Unix exposes path-based APIs, and file-handle-based APIs where Unix exposes file-handle-based APIs. So I agree that Rust's stdilb is somewhat mistake prone; not so much because it's being opinionated and "nudg[ing] the developer towards using neat APIs", but because it's so low-level that it's not offering much "safety" in filesystem access over raw syscalls beyond ensuring that you didn't write a buffer overflow. [0]: https://doc.rust-lang.org/std/fs/index.html https://doc.rust-lang.org/std/fs/index.html
      • masklinn 5mo ago
        > For example, Unix's `rename` syscall takes two paths as arguments; you can't rename a file by handle And then there’s renameat(2) which takes two dirfd… and two paths from there, which mostly has all the same issues rename(2) does (and does not even take flags so even O_NOFOLLOW is not available). I’m not sure what you’d need to make a safe renameat(), maybe a triplet of (dirfd, filefd, name[1]) from the source, (dirfd, name) from the target, and some sort of flag to indicate whether it is allowed to create, overwrite, or both. As the recent https://blog.sebastianwick.net/posts/how-hard-is-it-to-open-a-file/ https://blog.sebastianwick.net/posts/how-hard-is-it-to-open-... talks about (just for file but it applies to everything) secure file system interaction is absolutely heinous. [1]: not path
  • slopinthebag 5mo ago
    Seems pretty impressive they rewrote the coreutils in a new language, with so little Unix experience, and managed to do such a good job with very little bugs or vulns. I would have expected an order of magnitude more at least. Shows how good Rust is, that even inexperienced Unix devs can write stuff like this and make almost no mistakes.
    • nine_k 5mo ago
      Yes, it's the lack of Unix experience that's terrifying. So many of mistakes listed are rookie mistakes, like not propagating the most severe errors, or the `kill -1` thing. Why were people who apparently did not have much experience using coreutils assigned to rewrite coreutils?
      • aw1621107 5mo ago
        > Why were people who apparently did not have much experience using coreutils assigned to rewrite coreutils? From what I understand, "assigned" probably isn't the best way to put it. uutils started off back in 2013 as a way to learn Rust [0] way before the present kerfuffle. [0]: https://github.com/uutils/coreutils/tree/9653ed81a2fbf393f420d9a8007c574d922018d1 https://github.com/uutils/coreutils/tree/9653ed81a2fbf393f42...
        • nineteen999 5mo ago
          Yeah perhaps learning UNIX API's and Rust at the same time doesn't lead to a drop in replacement ready to be shipped in major distributions. Who whould have thunk it.
          • aw1621107 5mo ago
            Strictly speaking it doesn't preclude eventually producing a production-ready drop-in replacement either, though evidently that needs a fresh set of eyes.
        • bpbp-mango 5mo ago
  • pando85 5mo ago
    Memory safety catches buffer overflows. CI catches logic bugs. Neither catches the Unix API gotchas nobody documented.
    • cubefox 5mo ago
      LLM account
    • bjourne 5mo ago
      CI catches all kinds of bugs.
    • vhantz 5mo ago
      How does CI catch logic bugs?
      • bluGill 5mo ago
        That depends on what tests you are running. In any significant projects you need a test suite so large that you wouldn't run all the tests before pushing to CI - instead you are the targeted tests that test the area of code you changed, but there are more "integration tests" that go through you code and thus could break, but you don't actually run. You can also run some static analysis that is too long to run locally every time, but once in a while it will point out "this code pattern is legal buy is almost always a bug" It is also possible to do some formal analysis of code on CI that you wouldn't always run locally - I'm not an expert on these.
        • vhantz 5mo ago
          That's true in general. In this case where the logic bugs are from not understanding the API being implemented (and in any similar case), tests wouldn't catch the bugs either (even integration tests) because good tests require understanding the contract of the unit being tested.
    • Arch-TK 5mo ago
      They're not API gotchas in most cases. And writing comprehensive tests for this behaviour is very difficult regardless of which language you are using. I am all for rust rewrites of things. But in this case, these are mistakes which were encouraged by the lazy design of `std::fs` and the developers' lack of relevant experience. And to clarify, I don't blame the developers for lacking the relevant experience. Working on such a project is precisely the right place to learn stuff like this. I think it's an absurdly dumb move by Canonical to take this project and beta-test it on normal users' machines though…
  • concinds 5mo ago
    Reading that Canonical thread was jaw-dropping. Paraphrased: "Rust is more secure, security is our priority, therefore deploying this full-rewrite of core utils is an emergency. If things break that's fine, we'll fix it :)". I would not want to run any code on my machines made by people who think like this. And I'm pro-Rust. Rust is only "more secure" all else being equal. But all else is not equal. A rewrite necessarily has orders of magnitude more bugs and vulnerabilities than a decades-old well-maintained codebase, so the security argument was only valid for a long-term transition, not a rushed one. And the people downplaying user impact post-rollout, arguing that "this is how we'll surface bugs", and "the old coreutils didn't have proper test cases anyway" are so irresponsible. Users are not lab rats. Maintainers have a moral responsibility to not harm users' systems' reliability (I know that's a minority opinion these days). Their reasoning was flawed, and their values were wrong.
    • zx8080 5mo ago
      Agree with the point. Asking sincerely, how to filter out installing any rust-rewrite packages on my machines? Does anyone know the way?
      • kibwen 5mo ago
        If you don't want Canonical's packages, you should probably just be using Debian rather than Ubuntu. It's not 2008 anymore, stock Debian is quite user-friendly.
        • tambre 5mo ago
          Worth noting is that in Debian experimental coreutils defaults to coreutils-from-uutils [0]. This came as a big surprise and as far as I can tell there's been no discussion. A Canonical developer seems to have unilaterally overwritten the coreutils package without discussing with the maintainer. All the package renames that are in Ubuntu aren't in Debian so you can't switch to GNU utils either without deep trickery in a separate recovery environment. I'm used to running experimental software but I wasn't ready for my computer to not boot one day because of uutils. The `-Z` flag for `cp` wasn't implemented in the 9 month old version shipped in Debian at that time so initramfs creation failed... [0] https://packages.debian.org/experimental/coreutils https://packages.debian.org/experimental/coreutils
  • onlyrealcuzzo 5mo ago
    > They knew how to write Rust, but clearly weren't sufficiently experienced with Unix APIs, semantics, and pitfalls. The point of Rust is that you shouldn't have to worry about the biggest, easiest to fall in pitfalls. I think the author's point of this article, is that a proper file system API should do the same.
  • empath75 5mo ago
    Having panics in these are pretty amateur hour even just on a Rust level. I could see if they were like alloc errors which you can't handle, but expect and unwraps are inexcusable unless you are very carefully guarding them with invariants that prevent that code path from ever running.
• jolt42 5mo ago
  I wonder if Rust becomes more popular with AI as Rust can help catch what AI misses, but then if that's the case then what about Haskell, or Lean, or?
  • tayo42 5mo ago
    The way Haskell handles memory is weird and can be unpredictable.
  • hu3 5mo ago
    For core system functionality maybe. But for most applications Rust slow compiler iteration speed becomes a bottleneck when the likes of TypeScript (with Bun) and Go have sub second iteration times. Plus AI is also good at catching, in other languages, errors that Rust tooling enforces. Like race conditions, use after free, buffer overflows, lifetimes, etc. So maybe AI will become to ultimate "rust checker" for any language.
    • tnova 5mo ago
      In my experience developing different types of applications in Rust, the claims of a "slow compiler" are overstated. Sub second iteration times are definitely a thing in Rust as well, unless you're adding a new dependency for the first time or building fresh.
      • hu3 5mo ago
        Our experiences clearly differ then. And for others as well since it's a common complain. Countless time I have seen other people complain as well. There are articles about it even. Can't find the YouTube link now but recently a gamedev abandoned Rust due to compilation speed alone because iteration speed was paramount to their creative process. Handwaving isn't going to make it any better. And thinking Go/TS compilation speed are comparable to Rust is, a handwave and a half to say the least. Cargo check and friends are subpar for AI because they actually need to run the thing and unit tests for efficient agentic loops. A single loop might recompile and rerun the application/unit tests enough times that slow compilers like Rust and Scala become detrimental.
• marsven_422 5mo ago
  [dead]
• Scarbutt 5mo ago
  [flagged]
  • Ayaan2004 5mo ago
    windows also told us they will soon focus on rust to make operating system
  • mqus 5mo ago
    Bug =! Vulnerability
  • chiffaa 5mo ago
    Google people were specifically talking about memory safety. Logic bugs happen. All of the issues in TFA are effectively logic bugs or POSIX stuff, which is a different category entirely that Rust never claimed to solve
• collinfunk 5mo ago
  Hi, I am one of the maintainers of GNU Coreutils. Thanks for the article, it covers some interesting topics. In the little Rust that I have used, I have felt that it is far too easy to write TOCTOU races using std::fs. I hope the standard library gets an API similar to openat eventually. I just want to mention that I disagree with the section titled "Rule: Resolve Paths Before Comparing Them". Generally, it is better to make calls to fstat and compare the st_dev and st_ino. However, that was mentioned in the article. A side effect that seems less often considered is the performance impact. Here is an example in practice: $ mkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\n') $ while cd $(yes a/ | head -n 1024 | tr -d '\n'); do :; done 2>/dev/null $ echo a > file $ time cp file copy real 0m0.010s user 0m0.002s sys 0m0.003s $ time uu_cp file copy real 0m12.857s user 0m0.064s sys 0m12.702s I know people are very unlikely to do something like that in real life. However, GNU software tends to work very hard to avoid arbitrary limits [1]. Also, the larger point still stands, but the article says "The Rust rewrite has shipped zero of these [memory saftey bugs], over a comparable window of activity." However, this is not true [2]. :) [1] https://www.gnu.org/prep/standards/standards.html#Semantics https://www.gnu.org/prep/standards/standards.html#Semantics [2] https://github.com/advisories/GHSA-w9vv-q986-vj7x https://github.com/advisories/GHSA-w9vv-q986-vj7x
  • s20n 5mo ago
    Sorry, complete noob here. Why didn't you just cd into $(yes a/ | head -n $((32 * 1024)) | tr -d '\n')? Why do you need to use the while loop for cd? EDIT: got it. -bash: cd: a/a/a/....../a/a/: File name too long
    • collinfunk 5mo ago
      No need to apologize at all. Doing it in one cd invocation would fail since the file name is longer than PATH_MAX. In that case passing it to a system call would fail with errno set to ENAMETOOLONG. You could probably make the loop more efficient, but it works good enough. Also, some shells don't allow you to enter directories that deep entirely. It doesn't work on mksh, for example.
      • 5mo ago
• Analemma_ 5mo ago
  I know nobody's perfect and I'm not asking for perfection, but these bugs are pretty alarming? It seems like these supposed coreutils replacements are being written by people who don't know anything about Unix, and also didn't even bother looking at the GNU tools they are trying to replace. Or at least didn't have any curiosity about why the GNU tools work the way they do. Otherwise they might've wondered about why things operate on bytes and file descriptors instead of strings and paths. I hate to armchair general, but I clicked on this article expecting subtle race conditions or tricky ambiguous corners of the POSIX standard, and instead found that it seems to be amateur hour in uutils.
  • lelanthran 5mo ago
    > It seems like these supposed coreutils replacements are being written by people who don't know anything about Unix, and also didn't even bother looking at the GNU tools they were supposed to be replacing. They're a group of people who want to replace pro-user software (GPL) with pro-business software (MIT). I don't really want them to achieve their goal.
  • ronjakoi 5mo ago
    They are deliberately not looking at coreutils code because the Rust versions are released as MIT and they don't want the project contaminated by GPL. I am not fond of this, personally.
  • chiffaa 5mo ago
    Few things to note 1. uutils as a project started back in 2013 as a way to learn Rust, by no means by knowledgeable developers or in a mature language 2. uutils didn't even have a consideration to become a replacement of GNU Coreutils until.... roughly 2021, I think? 2021 is when they started running compliance/compatibility tests, anyway 3. The choice of licensing (made in 2013) effectively forbids them from looking at the original source
• tokyobreakfast 5mo ago
  [flagged]
• rvz 5mo ago
  This is what happens when many people hype about a technology that solves a specific class of vulnerabilities, but it is not designed to prevent the others such as logic errors because of human / AI error. Granted, the uutils authors are well experienced in Rust, but it is not enough for a large-scale rewrite like this and you can't assume that it's "secure" because of memory safety. In this case, this post tells us that Unix itself has thousands of gotchas and re-implementing the coreutils in Rust is not a silver bullet and even the bugs Unix (and even the POSIX standard) has are part of the specification, and can be later to be revealed as vulnerabilities in reality.
  • swiftcoder 5mo ago
    > the uutils authors are well experienced in Rust I'm not sure that they were all that experienced in Rust when most of this code was written. uutils has been a bit of a "good first rust issue" playground for a lot of its existence Which makes it pretty unsurprising that the authors also weren't all that well versed in the details of low-level POSIX API
  • IshKebab 5mo ago
    It's not designed to completely eliminate other bug classes but it is designed to reduce the chance that they happen. In this case the filesystem API was perhaps not as well designed as it could have been. That can potentially be fixed though. Some of the other bugs would be hard to statically prevent though. But nobody ever claimed otherwise.
• micheles 5mo ago
  > uutils now runs the upstream GNU coreutils test suite against itself in CI. That’s the right scale of defense for this class of bug. That's the minimum, it is absurd that they did not start from that!
  • aw1621107 5mo ago
    Looks like they've been doing at some kind of automated comparison against the GNU test suite since 2021 or so [0]? [0]: https://github.com/uutils/coreutils-tracking/commits/main/?after=e948aa9447568cbd3cf5484d56e25cb003c8f359+11500 https://github.com/uutils/coreutils-tracking/commits/main/?a...
  • jeroenhd 5mo ago
    I recall the last time there was a massive bug in the uutils project, it was because the coreutils tests didn't cover some crucial aspect people relied on. Running these tests is useful for compatibility and all, but it won't necessarily catch security issues.
  • ordu 5mo ago
    I believe they did it all the time. Maybe it was not automated? But they boasted in news multiple times how many coreutils tests they are passing. I suspect that those tests are useless for security, they are more about compatibility or something like that.
• slopinthebag 5mo ago
  I find it interesting how people will criticise Rust for not preventing all bugs, when the alternative languages don't prevent those same bugs nor the bugs rust does catch. If you're comparing Rust to a perfect language that doesn't exist, you should probably also compare your alternative to that perfect language as well right? I'd be interested in a comparison with the amount of bugs and CVE's in GNU coreutils at the start of its lifetime, and compare it with this rewrite. Same with the number of memory bugs that are impossible in (safe) Rust. Don't just downvote me, tell me how I'm wrong.
  • throawayonthe 5mo ago
    i don't think CVEs were a thing at the start of the GNU rewrite
  • flohofwoe 5mo ago
    What's the point of a "rewrite in Rust" when it introduces bugs that either never existed in the original or were fixed already? > I'd be interested in a comparison with the amount of bugs and CVE's in GNU coreutils at the start of its lifetime The point is, those bugs had been discovered and fixed decades ago. Do you want to wait decades for coreutils_rs to reach the same robustness? Why do a rewrite when the alternative is to help improve the original which is starting from a much more solid base? And even when a complete rewrite would make sense, why not do a careful line-by-line porting of the original code instead of doing a clean-room implementation to at least carry over the bugfixes from the original? And why even use the Rust stdlib at all when it contains footguns that are not acceptable for security-critical code?
    • slopinthebag 5mo ago
      Idk, you should ask the maintainers these questions, or the Ubuntu maintainers. I'm not particularly arguing in favour of this rewrite, but the title and contents of the post are talking about Rust in general and the type of bugs it can/can't prevent. Perhaps one good reason is that once the initial bugs are fixed, over time the number of security issues will be lower than the original? If it could reach the same level of stability and robustness in months or a small number of years, the downsides aren't totally obvious. We will have to wait to judge I suppose. Maybe it's not worth it and that's fine, but it doesn't speak to Rust as a language.
• 9fwfj9r 5mo ago
  So it's basically failing on - necessary atomicity for filesystem operation - annoying path & string encoding - inertia for historical behaviors
  • kibwen 5mo ago
    I'm comfortable saying that "annoying path & string encoding" is encompassed by "inertia for historical behaviors". :P
• fschuett 5mo ago
  Thanks for the list. I like these lists, so I can put them into a .md file, then launch "one agent per file" on my codebase and see if they can find anything similar to the mentioned CVEs. Rust won't catch it, but now the agents will. Edit: https://gist.github.com/fschutt/cc585703d52a9e1da8a06f9ef93cb5c6 https://gist.github.com/fschutt/cc585703d52a9e1da8a06f9ef93c... for anyone who needs copying this
  • deleted 5mo ago
    [deleted]
  • joaohaas 5mo ago
    Most (if not all) of these issues do not matter at all outside the scope GNU utils run in. For example, using filepaths instead of FDs does not matter in most cases in controlled server environments, or in processes that will never run with elevated privilege (most apps).
    • rstuart4133 5mo ago
      > Most (if not all) of these issues do not matter at all outside the scope GNU utils run in. I suspect that attitude is how we got ourselves into this mess. You have to assume you ultimately don't control what scope your software runs in. Obviously you do, 99.999% of the time. The other 0.0001% is when someone has found another vulnerability that lets them run your program with elevated privileges in an environment you didn't expect, and then they can use it to exploit one of these bugs. Almost all exploits use a chain of vulnerabilities each one seemingly mostly harmless - your "no one can ever exploit this weakness in my program because I control the environment" will be just one step in the chain. That sounds far fetched. It is far fetched in the sense that it almost never happens. But nonetheless systems were and are exploited because of it. Once the solution was added in 2006 (openat() and friends), it should have never happened again. And indeed in the GNU utils it can't. The people who build Rust's std::fs should have been aware of the problem and its solution because it was written in 2015. std::path was written at the same time, and that is where the change has to be made. It's not a big change either: std::path has to translate the path into a OS descriptor use that instead of the path - but only if it was available. I suspect the real issue was they had the same attitude as you, they thought it affects such a small percentage of programs it didn't really matter. That and it's a little bit of extra work. It was a pity they had that attitude, because the extra work would have avoided this mess.
• SpectreHat 5mo ago
  [dead]
• hombre_fatal 5mo ago
  One thing that's hard about rewriting code is that the original code was transformed incrementally over time in response to real world issues only found in production. The code gets silently encumbered with those lessons, and unless they are documented, there's a lot of hidden work that needs to be done before you actually reach parity. TFA is a good list of this exact sort of thing. Before you call people amateur for it, also consider it's one of the most softwarey things about writing software. It was bound to happen unless coreutils had really good technical docs and included tests for these cases that they ignored.
  • TheDong 5mo ago
    What's even harder is doing that while trying to avoid the GPL, so doing that without reading the original source code. uutils would be so much better imo if it was GPL and took direct inspiration from the coreutils source code.
    • dbdr 5mo ago
      The GPL prevents you from reading the licensed code before writing related non-GPL code? Which section of the GPL says that?
      • TheDong 5mo ago
        It's based on an interpretation of "derived from". It does not matter if it's in the GPL explicitly or not since we're talking about uutils and their stance on it, and they've written that: https://github.com/uutils/coreutils/blob/6b8a5a15b4f077f860943f4e431e26fbd56cda90/CONTRIBUTING.md#contributing-to-coreutils https://github.com/uutils/coreutils/blob/6b8a5a15b4f077f8609... > we cannot accept any changes based on the GNU source code [..]. It is however possible to look at other implementations under a BSD or MIT license like Apple's implementation or OpenBSD. The wording of that clearly implies that you should not look at GNU source code in order to contribute to uutils.
        • i_think_so 5mo ago
• immanuwell 5mo ago
  rust promised you memory safety and delivered - but turns out the filesystem doesn't care about your borrow checker, and these 44 cves are the receipt
• oconnor663 5mo ago
  > The trap is that get_user_by_name ends up loading shared libraries from the new root filesystem to resolve the username. That's kind of horrifying. Is there a reliable list somewhere of all the functions that do that? Is that list considered stable?
  • Joker_vD 5mo ago
    Nope! But basically, expect anything that resolves usernames, or host names, to be done in the userspace by NSS. Sun engineers Thomas Maslen and Sanjay Dani were the first to design and implement the Name Service Switch. They fulfilled Solaris requirements with the nsswitch.conf file specification and the implementation choice to load database access modules as dynamically loaded libraries, which Sun was also the first to introduce. Sun engineers' original design of the configuration file and runtime loading of name service back-end libraries has withstood the test of time as operating systems have evolved and new name services are introduced. Over the years, programmers ported the NSS configuration file with nearly identical implementations to many other operating systems including FreeBSD, NetBSD, Linux, HP-UX, IRIX and AIX.[citation needed] More than two decades after the NSS was invented, GNU libc implements it almost identically. It's by design, you see.
    • jsdfasds 5mo ago
      This is precisely why I don't link with glibc anymore.
      • Arch-TK 5mo ago
        musl has its own approach to this, it's called nscd It would have avoided the "running code as root" part, but it would still allow an attacker to control the result of the function call. I mean, the problem being solved here isn't exactly a bad problem to try to solve. You either permanently hard-code `/etc/passwd` as the user database, and `/etc/resolv.conf` as the source of DNS server information, or you allow these to be handled in a more complex way (thus allowing YellowPages, LDAP, or whatever you can imagine).
• Joker_vD 5mo ago
  > The pattern is always the same. You do one syscall to check something about a path, then another syscall to act on the same path. Between those two calls, an attacker with write access to a parent directory can swap the path component for a symbolic link. The kernel re-resolves the path from scratch on the second call, and the privileged action lands on the attacker’s chosen target. It's actually even worse than that somewhat, because the attacker with write access to a parent directory can mess with hard links as well... sure, it only messes with the regular files themselves but there is basically no mitigations. See e.g. [0] and other posts on the site. [0] https://michael.orlitzky.com/articles/posix_hardlink_heartache.xhtml https://michael.orlitzky.com/articles/posix_hardlink_heartac...
  • sysguest 5mo ago
    hmm... maybe a 'write lock' on the directory? though this will become more hairy without timeouts/etc...
    • masklinn 5mo ago
      To the extent that locking exists in posix it is various degrees of useless and broken. And as far as I know while BSDs have extensions which make some use cases workable Linux is completely hopeless.
• timcobb 5mo ago
  The title of this article should be "Rust can't stop you from not giving a fuck" or "Rust can't give a fuck for you." --- > What’s notable is that all of these bugs landed in a production Rust codebase, written by people who knew what they were doing ... [List of bugs a diligent person would be mindful of, unix expert or not] --- Only conclusion I can make is, unfortunately, the people writing these tools are not good software developers, certainly not sufficiently good for this line of work. For comparison, I am neither a unix neckbeard nor a rust expert, but with the magic of LLMs I am using rust to write a music player. The amount of tokens I've sunk into watching for undesirable panics or dropped errors is pretty substantial. Why? Because I don't want my music player to suck! Simple as that. If you don't think about panics or errors, your software is going to be erratic, unpredictable and confusing. Now, coreutils isn't my hobby music player, it's fundamental Internet infrastructure! I hate sounding like a Breitbart commenter but it is quite shocking to see the lack of basic thought going into writing what is meant to be critical infrastructure. Wow, honestly pathetic. Sorry to be so negative and for this word choice, but "shock" and "disappointment" are mild terms here for me. Anyway, thanks for the author of this post! This is a red flag that should be distributed far and wide.
  • MallocVoidstar 5mo ago
    > Pretty shocking to see the lack of basic thought going into writing what is meant to be critical infrastructure uutils did not start off as "let's make critical infrastructure in Rust", it started off as "coreutils are small and have tests, so we're rewriting them in Rust for fun". As a result there's needed to be a bunch of cleanup work.
    • timcobb 5mo ago
      Okay, thanks for the context, but aren't distributions eager to adopt these? Are current GNU coreutils a common vulnerability vector? > For fun My idea of fun is reviewing my code and making sure I'm handling errors correctly so that my software doesn't suck. Maybe the people who are doing this, for fun, should be more aligned with that mentality?
      • 5mo ago
• misja111 5mo ago
  The root cause of some of the bugs seems to be the opaque nature of some of the Unix API. E.g. > The trap is that get_user_by_name ends up loading shared libraries from the new root filesystem to resolve the username. An attacker who can plant a file in the chroot gets to run code as uid 0. To me such a get_user_by_name function is like a booby trap, an accident that is waiting to happen. You need to have user data, you have this get_user_by_name function, and then it goes and starts loading shared libraries. This smells like mixing of concerns to me. I'd say, either split getting the user data and loading any shared libraries in two separate functions, or somehow make it clear in the function name what it is doing.
  • geocar 5mo ago
    > The root cause of some of the bugs seems to be the opaque nature of some of the Unix API. Seems and smells is weasel words. The root cause is not thinking: Why is root chrooting into a directory they do not control? Whatever you chroot into is under control of whoever made that chroot, and if you cannot understand this you have no business using chroot() > To me such a get_user_by_name function is like a booby trap > I'd say, either split getting the user data and loading any shared libraries in two separate functions, or somehow make it clear in the function name what it is doing. You'd probably still be in the trap: there's usually very little difference between writing to newroot/etc/passwd and newroot/usr/lib/x86_64-linux-gnu/libnss_compat.so or newroot/bin/sh or anything else. So I think there's no reason for /usr/sbin/chroot look up the user id in the first place (toybox chroot doesn't!), so I think the bug was doing anything at all.
    • Joker_vD 5mo ago
      > The root cause is not thinking: Why is root chrooting into a directory they do not control? Because you can't call chroot(2) unless you're root. And "control a directory" is weasel words; root technically controls everything in one sense of the word. It can also gain full control (in a slightly different sense of the word) over a directory: kill every single process that's owned by the owner of that directory, then don't setuid into that user in this process and in any other process that the root currently executes, or will execute, until you're done with this directory. But that's just not useful for actual use, isn't it? Secure things should be simple to do, and potentially unsafe things should be possible.
• alkonaut 5mo ago
  > What’s notable is that all of these bugs landed in a production Rust codebase, written by people who knew what they were doing So does this mean that neither did the original utils have any test harness, the process of rewriting them didn't start by creating one either? Sure there are many edge cases, but surely the OS and FS can just be abstracted away and you can verify that "rm .//" actually ends up doing what is expected (Such as not deleting the current directory)? This doesn't seem like sloppy coding, nor a critique of the language, it's just the same old "Oh, this is systems programming, we don't do tests"? Alternatively: if the original utils _did_ have tests, and there were this many holes in the tests, then maybe there is a massive lack in the original utils test suite?
  • omcnoe 5mo ago
    My understanding is the uutils development process involved extensive testing against the behaviour of the original utilities, including preserving bugs.
    • alkonaut 5mo ago
      But we still have CVE's for trivial things? I mean just a medium sized test suite for "rm" alone should probably be many thousand test cases or so. And you'd think that deleting "." and "./" respectively would be among them? Hindsight is always 20/20 and for inputs involving text input you can never be entirely covered, but still....
    • 12_throw_away 5mo ago
      If something as basic as "rm ./" is broken, the word "extensive" does not apply to whatever testing there was.
  • geocar 5mo ago
    > So does this mean that neither did the original utils have any test harness, the process of rewriting them didn't start by creating one either? Yes. > Sure there are many edge cases, but surely the OS and FS can just be abstracted away and you can verify that "rm .//" actually ends up doing what is expected (Such as not deleting the current directory)? I think people have been trying that since before I was born and haven't yet been successful, so I am much less sure than you are. For example: How do you decide how many `/` characters to try? For a better one: Can you imagine if "rm" could simply decide to refuse to delete files containing "important" as first 9 bytes? How would you think of a test for something like that without knowing the letters in that order? What if the magic word wasn't in a dictionary? > This doesn't seem like sloppy coding, nor a critique of the language, it's just the same old "Oh, this is systems programming, we don't do tests"? I've never heard anyone say that except as a straw man. I've heard people say tests don't do what people think they do.
• amelius 5mo ago
  [flagged]
• tdiff 5mo ago
  Ok if there were some rust guys rewriting coreutils with no experience in linux, but how come Ubuntu accepted it into its mainline?
  • Joeboy 5mo ago
    Because it's Ubuntu policy to replace some foundational part of the system with some janky unfinished experiment in every release. I agree with you that that's more the story here than "OMG, somebody wrote Rust code with bugs in it".
    • 12_throw_away 5mo ago
      Right? Canonical wanted (still wants?) to use a coreutils implementation where "rm ./" would print "invalid input" while silently deleting the directory anyway. I don't really care that some very amateur enthusiasts wrote some bad code for fun, but how in the world did anyone who knows anything about linux take this seriously as a coreutils replacement?
  • foobar1274278 5mo ago
    The original is GPL licensed, while the rewrite is MIT.
    • tdiff 5mo ago
      Was at actually so important to rush with the switch?
• jonjon16 5mo ago
  [flagged]
• osmsucks 5mo ago
  I feel like one of the takeaways here is that Rust protects your code as long as what your code is doing stays predictably in-process. Touching the filesystem is always ripe with runtime failures that your programming language just can't protect you from. (Or maybe it also suggests the `std::fs` API needs to be reworked to make some of these occurrences, if not impossible, at least harder.) On a separate note: I have a private "coretools" reimplementation in Zig (not aiming to replace anything, just for fun), and I'm striving to keep it 100% Zig with no libc calls anywhere. Which may or may not turn out to be possible, we'll see. However, cross-checking uutils I noticed it does have a bunch of unsafe blocks that call into libc, e.g. https://github.com/uutils/coreutils/blob/77302dbc87bcc7caf875bc019912b698ca4d8fbf/src/uu/logname/src/logname.rs#L15 https://github.com/uutils/coreutils/blob/77302dbc87bcc7caf87.... Thankfully they're pretty minimal, but every such block can reduce the safety provided by a Rust rewrite.
  • aw1621107 5mo ago
    > and I'm striving to keep it 100% Zig with no libc calls anywhere. Which may or may not turn out to be possible, we'll see. Probably will depend on what platform(s) you're targeting and/or your appetite for dealing with breakage. You can avoid libc on Linux due to its stable syscall interface, but that's not necessarily an option on other platforms. macOS, for instance, can and does break syscall compatibility and requires you to go through libSystem instead. Go got bit by this [0]. I want to say something similar applies to Windows as well. This Unix StackExchange answer [1] says that quite a few other kernels don't promise syscall compatibility either, though you might be able to somewhat get away with it in practice for some of them. [0]: https://github.com/golang/go/issues/17490 https://github.com/golang/go/issues/17490 [1]: https://unix.stackexchange.com/a/760657 https://unix.stackexchange.com/a/760657
    • osmsucks 5mo ago
      Since it's a personal project, Linux compatibility is the only thing I care about right now. I'm testing it under WINE as well, just because I can, but I don't have access to Mac OS so I'm skipping that problem entirely for now
• einpoklum 5mo ago
  Note: TOCTOU means "Time-of-check to time-of-use" See also: https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use
• marcosscriven 5mo ago
  That’s a great article, and indeed a very good blog. Just spent ages reading lots of their other articles. Of the bugs mentioned I think the most unforgivable one is the lossy UTF conversion. The mind boggles at that one!
• eb08a167 5mo ago
  I'm totally fine with people experimenting and making amateur attempts at what adult people do. After all, that's how we grow. What I'm actually curious about is how the decision-making chain at Ubuntu got so messed up that this made it into production.
  • eviks 5mo ago
    Sometimes growing is only your height increasing
• r2vcap 5mo ago
  Just use Fedora :)
  • bombcar 5mo ago
    All the cool kids are using Gentoo or Nix ;)
• lionkor 5mo ago
  I struggle to find anything on this post that wouldn't be caught by some kind of unit test or manual review, especially when comparing with the GNU source for the coreutils. The whole coreutils rewrite is a terrible idea[1] and clearly being done in the wrong way (without the knowledge gained from the previous software). If you do a rewrite, you should fully understand and learn from the predecessor, otherwise youre bound to repeat all the mistakes. Embarassing. To be clear; I love Rust, I use it for various projects, and it's great. It doesn't save you from bad engineering. [1]: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
  • cwillu 5mo ago
    I expect nothing less from the creators of unity, upstart, and snap.
  • dwattttt 5mo ago
    > I struggle to find anything on this post that wouldn't be caught by some kind of unit test or manual review, especially when comparing with the GNU source for the coreutils. > If you do a rewrite, you should fully understand and learn from the predecessor, otherwise youre bound to repeat all the mistakes. Embarassing. Interestingly, the uutils project uses the GNU coreutils test suite. EDITED to add: they also have a stated position of not allowing contributions based on reading the GPL'd source.
  • a-dub 5mo ago
    welcome new systems programmers: unix is broken and you must write ugly non-pedagogical workarounds and do empirical testing. this is what reliable software and good software engineering actually is... surprise!@#%
• z3t4 5mo ago
  To be fair these are mostly gotchas with Linux and not Rust itself, but I guess the std in Rust could handle some of these issues, in that a std should not allow you to shoot yourself in the foot by default.
• melodyogonna 5mo ago
  TL;DR: Rust can't catch logic bugs
  • mre 5mo ago
    [dead]
• bayindirh 5mo ago
  > This is the largest cluster of bugs in the audit. It’s also the reason cp, mv, and rm are still GNU in Ubuntu 26.04 LTS. :( This is what grinds my gears. Why all the hate against GNU? Honestly, this is why I don't learn Rust, and why I didn't bother to read the rest of the article.
  • kibwen 5mo ago
    Rust does not hate GNU, and I'm not sure why anyone would have that misconception. It would be like saying that C hates GNU because the BSDs aren't GNU. The fact that there is less GNU-licensed Rust software than MIT-licensed Rust software is attributable to the simple fact that, in general, GNU has been ceding ground to MIT for more than 20 years.
    • Pay08 5mo ago
      Nor does the parent comment say that "Rust" hates GNU. A language can't hate anything for that matter.
• PunchyHamster 5mo ago
  Seems like typical pattern of * Let's rewrite thing in X, it is better * Let's not look at existing code, X is better so writing it from scratch will look nicer * Whoops, existing code was written like this for a reason * Whoops, we re-introduce decade+ old problems that original already fixed at some point
  • Bridged7756 5mo ago
    I call it FOTM engineering. Let's throw everything out of the window so we can use X novel thing!
• bluGill 5mo ago
  I have to partially disagree with applying Hyrum's law here. In the case of core utils, there's not just the common GNU version. There's also what POSIX says they should do and what the various BSD does, plus some other implementations from various vendors that we mostly forget about. If in any case what this version of Core Utils does is different from what GNU does in a way that others are also different, it would be a good thing to break behavior because anyone's script already is wrong in ways that are going to matter in the real world and it may matter in the future anyway, so breaking them now is good. If your script depends on GNU's behavior, then you shouldn't be calling the standard version. You should be explicitly specifying the GNU version. That is, don't use CP. Use GNU-CP or whatever it is commonly installed at. Or you check for what version of CP you have.
  • aragilar 5mo ago
    But if you seek to replace coreutils (as at least is the case with Canonical it seems), rather than just be another POSIX userland implementation (e.g. busybox), then I would suggest you do need to be bug-compatible? I can apt/dnf/apk install busybox and use that for my user rather than coreutils, but given a significant amount of Linux infrastructure (including likely many personal scripts) are tied to coreutils, the bar is much higher. Given the numerous issues with quality Canonical has had, not just with Ubuntu but their other "commercial" tooling, I'm not sure any rewrite/port, written in rust or otherwise, with Canonical developing, managing, or even being associated with the project can meet the requisite bar.
    • bluGill 5mo ago
      As someone who prefers BSD I would make it my goal to become something reasonably popular on linux that isn't different just to force less reliance of the GNUisms in their core utils. Nothing wrong with the GNUisms on the command line, but there are are a lot of GNU assumptions in scripts that should be portable.
• stackedinserter 5mo ago
  TIL that > uutils read it as “send the default signal to PID -1”, which on Linux means every process you can see. What's the use case for killing all process you can see?
  • geocar 5mo ago
    kill -SIGWINCH -1 will redraw all your windows.
  • Arch-TK 5mo ago
    Many cases, including as a last resort as part of shutdown, to try to trigger remaining services into a graceful exit (although these days cgroups help avoid ever being in such a situation).
• satvikpendem 5mo ago
  Unrelated but also in the category of bugs Rust won't catch (natively), there are crates that allow C++ style contracts, or more generally, dependent typing and can be used to catch issues at compile time rather than runtime. I use this one, anodized. https://docs.rs/anodized/latest/anodized/ https://docs.rs/anodized/latest/anodized/
  • ozgrakkurt 5mo ago
    What do you think about the mental load and ergonomics this brings into the code? Also compilation time increase?
    • satvikpendem 5mo ago
      There is some compile time increase but it brings a lot more guarantees to the code. There was a recent post by a Rust maintainer that he wanted to bring Rust closer to a theorem prover so that as many things as possible can be caught during compile time over time time which might be more disastrous.
• sennalen 5mo ago
  Reversing max and min. That's one I've done a lot, and I don't think any compiler could save me from.
• provenpath 5mo ago
  [dead]
• nottorp 5mo ago
  > Rust’s standard library makes this easy to get wrong. The ergonomic APIs you reach for first (fs::metadata, File::create, fs::remove_file, fs::set_permissions) all take a path and re-resolve it every time, rather than taking a file descriptor and operating relative to that. That’s fine for a normal program, but if you’re writing a privileged tool that needs to be secure against local attackers, you have to be careful. It's not fine even for a normal program, because operations on a large number of files will end up an order of magnitude slower. No matter what language you write your utility in. ... reads the article to the end, marvels at all the problems resulting from not understanding how the OS works and missing 40 years of refinement ... Is this in an Ubuntu LTS ?!?
• nixpulvis 5mo ago
  > These are noisy in test code where panicking on bad data is exactly what you want. The cleanest way to scope them to non-test code is to put #![cfg_attr(test, allow(clippy::unwrap_used, clippy::expect_used, clippy::panic, clippy::indexing_slicing, clippy::arithmetic_side_effects))] at the top of each crate root, or to gate #[allow(...)] on the individual #[cfg(test)] modules. Surely there's a better way.
  • kibwen 5mo ago
    Clippy doesn't even run on unit tests by default. Honestly it doesn't seem very useful to have it do so for ordinary development, but maybe you'd want to run Clippy on your unit tests in CI just to be extra safe, in which case you could encode those allowed lints in the line of your CI config where you run `cargo clippy`, e.g. `cargo clippy -- -A unwrap_used -A expect_used -A panic -A indexing_slicing -A arithmetic_side_effects`, if you really didn't want to have them in the source for whatever reason.
    • estebank 5mo ago
      Delaying the run of clippy until CI would be annoying, because then you'd get a build failure for something that was preventable and could have been quickly addresses during development before pushing. Just feels like a pebble in your shoe.
• mayhemducks 5mo ago
  I enjoyed reading this. I LOL'd when I read "eternal ball of sadness".
• techpulselab 5mo ago
  [dead]
• streetfighter64 5mo ago
  > That means, even if the tools were (and probably still are) buggy, they never had a bug that could be exploited to read arbitrary memory. Well, that begs the question, is it worse to read arbitrary memory (which would probably in most cases be prevented by various dynamic protections [0] anyway), or failing to prevent rm -rf /./ and killing every process in the system, etc.? This is still a good case study of the value of the much-touted rust rewrites. Usually they are performed by people who are domain experts in rust, but (as seen here) lack basic domain knowledge of the tool's environment. [0] https://en.wikipedia.org/wiki/Buffer_overflow_protection https://en.wikipedia.org/wiki/Buffer_overflow_protection
• _alphageek 5mo ago
  [dead]
• abbeyj 5mo ago
  > The Python one-liner is there because most modern shells refuse to create a non-UTF-8 filename for you. Both `echo -ne 'weird\xffname\0' > list0` and `printf 'weird\xffname\0' > list0` seem to work fine for me on Linux. Is this macOS-specific?
  • deathanatos 5mo ago
    > Both `echo -ne 'weird\xffname\0' > list0` and `printf 'weird\xffname\0' > list0` seem to work fine for me on Linux. Is this macOS-specific? Neither of those create a non-UTF-8 filename. (Both files are named "list0", which is valid UTF-8.) They have non-UTF-8 content, but that's not weird. But it's not too hard to get a non-UTF-8 filename: touch $'\xff' Both zsh & bash support that syntax. (You could also use process substitution with printf, but that's more steps than necessary. So, something closer to your example would be, touch "$(printf '\xff')" You can't put a \0 in the filename, as there's no way to pass that string in C.)
• throw7 5mo ago
  The "kill -1" is hilarious. I wouldn't use ubuntu for production for quite awhile while things shake out or, probably, never (since i don't use ubuntu).
• dlahoda 5mo ago
  Why differential fuzzing did not catch these bugs? https://github.com/uutils/coreutils/tree/main/fuzz/uufuzz https://github.com/uutils/coreutils/tree/main/fuzz/uufuzz
  • ozgrakkurt 5mo ago
    Looks like it doesn't really fuzz much. https://github.com/uutils/coreutils/tree/main/fuzz/fuzz_targets https://github.com/uutils/coreutils/tree/main/fuzz/fuzz_targ... Maybe these tests aren't even fuzz tests? https://github.com/uutils/coreutils/blob/main/fuzz/fuzz_targets/fuzz_seq.rs https://github.com/uutils/coreutils/blob/main/fuzz/fuzz_targ... Even the tests that look ok are not that good in my opinion because there is no structure to it: https://github.com/uutils/coreutils/blob/main/fuzz/fuzz_targets/fuzz_seq_parse_number.rs https://github.com/uutils/coreutils/blob/main/fuzz/fuzz_targ... It should also try to generate mostly correct but slightly wrong things instead of just dumping random data into it. Seems to also not expect some fuzz tests to even pass in the CI: https://github.com/uutils/coreutils/blob/a07879b8ab2bb8fe5e0f6ae3e9312bd4fb8fd4aa/.github/workflows/fuzzing.yml#L88 https://github.com/uutils/coreutils/blob/a07879b8ab2bb8fe5e0...
• penguin_booze 5mo ago
  The correct phrasing of the title: The bugs Rust won't catch.
• Dorrell 5mo ago
  [flagged]