lcamtuf :verified: :verified: :verified: (@lcamtuf@infosec.exchange)
infosec.exchange
The coreutils Rust rewrite story is pretty funny. Coreutils are tools like rm, mv, mkdir, etc. Unlike binutils, this isn't a fertile ground for memory safety bugs. But, the rewrite was completed, and in the spirit of progress, Canonical decided to switch. But do you know what coreutils are a fertile ground for? Race conditions around file creation, deletion, permission setting, and so on. The original code accounted for decades of hard-learned lessons in that space. The Rust rewrite did not: https://seclists.org/oss-sec/2026/q2/332 PS. I'm not dunking on Rust. It's just that... starting over from scratch has its hidden costs.
  • Solemarc@lemmy.world
    10·
    3 days ago

    I know we’ve all heard Microsoft and google say that 70% of their bugs are memory safety issues, but the GNU core utils don’t really have that problem. They’re small, simple, short lived programs and most of the problems they have arent memory related.

    Most of the CVE’s we’ve seen since Ubuntu picked the rust version up are logic issues and race conditions.

    • onlinepersona@programming.dev
      31·
      3 days ago

      Regardless of how secure and safe GNU coreutils are, requiring people to learn a memory unsafe language in order to contribute isn’t good. It’s the same as having COBOL control most of the financial system and other legacy systems. It’s better to rewrite those things in modern languages early on than 50, 70 or 100 years later.

      Bugs will occur, that’s hardly an argument against progress nor is it an argument for standing still. It’s good that bugs existed. It was a learning opportunity for the rust core utils. We learn by making mistakes. The people involved in the bug fixing and those who read the bug reports undoubtedly learned a thing or two that they can use to improve the rust ecosystem and bring to other projects.

      CVEs exist and will continue to exist as long as software exists. Logic CVEs will probably exist forever, but practically eliminating an entire class (memory safety CVEs) allows concentrating on logic. I’d argue that’s a much better way forward.

      • MonkderVierte@lemmy.zip
        7·
        2 days ago

        There’s not much to contribute there. They are small simple utilities some Unix admin wrote for their own convenience some 50 years ago. The equivalent to a little shell script, where they had not much shell yet.
        GNU overengineered them a bit and that’s it.

        Their point is, that every system has them, with the same interfaces and behavior everywhere.
        If you have to rewrite them, make them better but name them differently. Like tools like ripgrep, fd, bat and the like.

        • onlinepersona@programming.dev
          23·
          2 days ago

          Wy rename them? This exactly gives people the opportunity to contribute stuff to standard tooling without having to go through a mailing list and with a much better developer experience.

          Yes, it’s on Microslop Github, but I have hope they’ll see the light and move away from that AI riddled big tech platform. At the latest when forgejo or another forge implements federation.

          • MonkderVierte@lemmy.zip
            5·
            2 days ago

            Wy rename them?

            Because they have to work 100% like the original tools otherwise. I will not write compatibility checks for the -rs set in my scripts and likely nobody else too. Even POSIX compatibility is often already expected too much.

            • onlinepersona@programming.dev
              13·
              2 days ago

              Why so they have to work 100% like the original tools? Why can’t it overlap and add more? Why can’t it remove features that are confusing or a security liability?