4 ms·

> In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages > Critical infra

> In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages > Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. But hasn't all that foundational code been stable and wrung out already over the last 30+ years? The .tar and .ar file formats are both from the 70s; what new benefits will users or developers gain from that thoroughly battle-tested code being thrown out and rewritten in a new language with a whole new set of compatibility issues and bugs?

ok123456 11mo ago
There are none. This is a canonical employee trying to force Ubuntu's decisions (rust coretools) on the wider Debian community. Additionally, the fact that this comes across as so abrasive and off-putting is on brand for online Rust evangelicalism.
blub 11mo ago
Recently the rust coreutils had a bug and this essentially disabled auto-updates on Ubuntu. :) Seeing this tone-deaf message from an Ubuntu employee would be funny if I didn’t actually use Ubuntu. Looks like I have to correct that…
- julian-klode 11mo ago
  Isn't it also funny that all of these things are done by the same person? In all seriousness though, let me assure you that I plan to take a very considerate approach to Rust in APT. A significant benefit of doing Rust in APT rather than rewriting APT from scratch in Rust means that we can avoid redoing all our past mistakes because we can look at our own code and translate it directly.
  - RustSupremacist 11mo ago
    You have never been skilled at being considerate: https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104401817 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
    - chris_wot 11mo ago
      Christ that was handled badly.
  - rpcope1 11mo ago
    Honestly having seen trainwreck after trainwreck after trainwreck come out of Canonical for the last decade, I'm sure I'm not the only one that has strong doubts about anyone associated being able to "avoid redoing past mistakes" or to make things not suck.
  - blub 11mo ago
    Seems reasonable. I wish you would have written that in your original message. Good luck…
Denvercoder9 11mo ago
> But hasn't all that foundational code been stable and wrung out already over the last 30+ years? No: a little less than 5 years ago there was CVE-2020-27350, a memory safety bug in the tar/ar implementations.
- Arrowmaster 11mo ago
  But just this year there was CVE-2025-62518 in tokio-tar.
hiccuphippo 11mo ago
Every software is stable and wrung out until someone finds an exploit.
jcranmer 11mo ago
> But hasn't all that foundational code been stable and wrung out already over the last 30+ years? Not necessarily. The "HTTP signature verification code" sounds like it's invoking cryptography, and the sense I've had from watching the people who maintain cryptographic libraries is that the "foundational code" is the sort of stuff you should run away screaming from. In general, it seems to me to be the cryptography folks who have beat the drum hardest for moving to Rust. As for other kind of parsing code, the various archive file formats aren't exactly evolving, so there's little reason to update them. On the other hand, this is exactly the kind of space where there's critical infrastructure that has probably had very little investment in adversarial testing either in the past or present, and so it's not clear that their age has actually led to security-critical bugs being shaken out. Much as how OpenSSL had a trivially-exploitable, high criticality exploit for two years before anybody noticed.
- bgwalter 11mo ago
  If you mean GnuPG, that is what Snowden used. It could be better than new software that may have new bugs. Memory safety is a very small part of cryptographic safety. (New cryptographic software can also be developed by all sorts of people. In this case I'm not familiar, but we do know that GnuPG worked for the highest profile case imaginable.)
  - pclmulqdq 11mo ago
    GPG works great if you use it to encrypt and decrypt emails manually as the authors intended. The PGP/GPG algorithms were never intended for use in APIs or web interfaces. Ironically, it was the urge not to roll your own cryptography that got people caught in GPG-related security vulnerabilities.
- julian-klode 11mo ago
  Actual cryptography code, the best path is formally verified implementations of the crypto algorithms; with parsers for wrapper formats like OpenPGP or PKCS#7 implemented in a memory safe language. You don't want the core cryptography implemented in Rust for Rust's sake when there's a formally verified Assembler version next to it. Formally verified _always_ beats anything else.
julian-klode 11mo ago
I wish, but I get new security bugs in those components like every year or so, not all are tracked with security updates to be fair, some we say it's your own fault if you use the library to parse untrusted code. After all the library wasn't designed around safety, we assumed the .debs you pass to it are trusted in some way - because you publish them to your repository or you are about to install them so they have root maintainer scripts anyway. But as stuff like hosting sites and PPAs came up, we have operators publishing debs for untrusted users, and hence suddenly there was a security boundary of sorts and these bugs became problematic. Of course memory safety here is only one concern, if you have say one process publishing repos for multiple users, panics can also cause a denial of service, but it's a step forward from potential code execution exploits. I anticipate the rewrites to be 1 to 1 as close as possible to avoid introducing bugs, but then adding actual unit tests to them.
- RustSupremacist 11mo ago
  "The best laid plans of mice and men often go awry."
deleted 11mo ago
[deleted]

ok123456 11mo ago

There are none. This is a canonical employee trying to force Ubuntu's decisions (rust coretools) on the wider Debian community. Additionally, the fact that this comes across as so abrasive and off-putting is on brand for online Rust evangelicalism.

blub 11mo ago

Recently the rust coreutils had a bug and this essentially disabled auto-updates on Ubuntu. :) Seeing this tone-deaf message from an Ubuntu employee would be funny if I didn’t actually use Ubuntu. Looks like I have to correct that…

julian-klode 11mo ago
Isn't it also funny that all of these things are done by the same person? In all seriousness though, let me assure you that I plan to take a very considerate approach to Rust in APT. A significant benefit of doing Rust in APT rather than rewriting APT from scratch in Rust means that we can avoid redoing all our past mistakes because we can look at our own code and translate it directly.
- RustSupremacist 11mo ago
  You have never been skilled at being considerate: https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104401817 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
  - chris_wot 11mo ago
    Christ that was handled badly.
- rpcope1 11mo ago
  Honestly having seen trainwreck after trainwreck after trainwreck come out of Canonical for the last decade, I'm sure I'm not the only one that has strong doubts about anyone associated being able to "avoid redoing past mistakes" or to make things not suck.
- blub 11mo ago
  Seems reasonable. I wish you would have written that in your original message. Good luck…

Denvercoder9 11mo ago

> But hasn't all that foundational code been stable and wrung out already over the last 30+ years? No: a little less than 5 years ago there was CVE-2020-27350, a memory safety bug in the tar/ar implementations.

Arrowmaster 11mo ago
But just this year there was CVE-2025-62518 in tokio-tar.

hiccuphippo 11mo ago

Every software is stable and wrung out until someone finds an exploit.

jcranmer 11mo ago

> But hasn't all that foundational code been stable and wrung out already over the last 30+ years? Not necessarily. The "HTTP signature verification code" sounds like it's invoking cryptography, and the sense I've had from watching the people who maintain cryptographic libraries is that the "foundational code" is the sort of stuff you should run away screaming from. In general, it seems to me to be the cryptography folks who have beat the drum hardest for moving to Rust. As for other kind of parsing code, the various archive file formats aren't exactly evolving, so there's little reason to update them. On the other hand, this is exactly the kind of space where there's critical infrastructure that has probably had very little investment in adversarial testing either in the past or present, and so it's not clear that their age has actually led to security-critical bugs being shaken out. Much as how OpenSSL had a trivially-exploitable, high criticality exploit for two years before anybody noticed.

bgwalter 11mo ago
If you mean GnuPG, that is what Snowden used. It could be better than new software that may have new bugs. Memory safety is a very small part of cryptographic safety. (New cryptographic software can also be developed by all sorts of people. In this case I'm not familiar, but we do know that GnuPG worked for the highest profile case imaginable.)
- pclmulqdq 11mo ago
  GPG works great if you use it to encrypt and decrypt emails manually as the authors intended. The PGP/GPG algorithms were never intended for use in APIs or web interfaces. Ironically, it was the urge not to roll your own cryptography that got people caught in GPG-related security vulnerabilities.
julian-klode 11mo ago
Actual cryptography code, the best path is formally verified implementations of the crypto algorithms; with parsers for wrapper formats like OpenPGP or PKCS#7 implemented in a memory safe language. You don't want the core cryptography implemented in Rust for Rust's sake when there's a formally verified Assembler version next to it. Formally verified _always_ beats anything else.

julian-klode 11mo ago

I wish, but I get new security bugs in those components like every year or so, not all are tracked with security updates to be fair, some we say it's your own fault if you use the library to parse untrusted code. After all the library wasn't designed around safety, we assumed the .debs you pass to it are trusted in some way - because you publish them to your repository or you are about to install them so they have root maintainer scripts anyway. But as stuff like hosting sites and PPAs came up, we have operators publishing debs for untrusted users, and hence suddenly there was a security boundary of sorts and these bugs became problematic. Of course memory safety here is only one concern, if you have say one process publishing repos for multiple users, panics can also cause a denial of service, but it's a step forward from potential code execution exploits. I anticipate the rewrites to be 1 to 1 as close as possible to avoid introducing bugs, but then adding actual unit tests to them.

RustSupremacist 11mo ago
"The best laid plans of mice and men often go awry."

deleted 11mo ago

[deleted]