3 ms·

In the era of modern CI and build infrastructure, I don't really think that's materially an issue.

ok123456 3y ago
Those CI and build infrastructures rely on the Debian and RedHat being able to build system packages. How would an automated CI or build infrastructure stop this attack? It was stopped because the competent package maintainer noticed a performance regression. In this case, this imagined build system would have to track every rust library used in every package to know which packages to perform an emergency release for.
- packetlost 3y ago
  I... don't see your point. Tracking the dependencies a static binary is built with is already a feature for build systems, just maybe not the ones Debian and RH are using now, but I imagine they would if they were shipping static binaries. Rust isn't really the point here, it's the age old static vs dynamic linking argument. Rust (or rather, Cargo) already tracks which version of a dependency a library depends on (or a pattern to resolve one), but it's besides the point.
  - ok123456 3y ago
    Rust is the issue here because it doesn't give you much of an option. And that option is the wrong one if you need to do an emergency upgrade of a particular library system-wide.
    - packetlost 3y ago
      It's really not, it's not hard to do a reverse search of [broken lib] <= depends on <= [rust application] and then rebuild everything that matches. You might have to rebuild more, but that's not really hard with modern build infrastructure. Not to mention if you have a Rust application that depends on C libraries, it already dynamically links on most platforms. You only need to rebuild if a Rust crate needs to be updated.
- steveklabnik 3y ago
  > imagined Cargo already has this information for every project it builds. That other systems do not is their issue, but it’s not a theoretical design.
  - ok123456 3y ago
    So, I know that librustxz has been compromised. I'm Debian. I must dive into each rust binary I distribute as part of my system and inspect their Cargo.toml files. Then what? Do I fork each one, bump the version, hope it doesn't break everything, and then push an emergency release!??!
    - steveklabnik 3y ago
      > I must dive into each rust binary I distribute as part of my system and inspect their Cargo.toml A few things: 1. It'd be Cargo.lock 2. Debian, in particular, processes Cargo's output here and makes individual debs. So they've taken advantage of this to already know via their regular package manager tooling. 3. You wouldn't dive into and look through these by hand, you'd have it as a first-class concept. "Which packages use this package" should be table stakes for a package manager. > Then what? Do I fork each one, bump the version, hope it doesn't break everything, and then push an emergency release!??! The exact same thing you do in this current situation? It depends on what the issue is. Cargo isn't magic. The point is just that "which libraries does the binary depend on" isn't a problem with actual tooling. People already run tools like cargo-vet in CI to catch versions of packages that may have issues they care about.
      - ok123456 3y ago
        > The exact same thing you do in this current situation? It depends on what the issue is. Cargo isn't magic. False. In the current situation, you just release a new shared library that is used system-wide.
        steveklabnik 3y ago
        Okay, so the analogous situation here is that you release a new version of the library, and rebuild. Done.

Those CI and build infrastructures rely on the Debian and RedHat being able to build system packages. How would an automated CI or build infrastructure stop this attack? It was stopped because the competent package maintainer noticed a performance regression. In this case, this imagined build system would have to track every rust library used in every package to know which packages to perform an emergency release for.

packetlost 3y ago
I... don't see your point. Tracking the dependencies a static binary is built with is already a feature for build systems, just maybe not the ones Debian and RH are using now, but I imagine they would if they were shipping static binaries. Rust isn't really the point here, it's the age old static vs dynamic linking argument. Rust (or rather, Cargo) already tracks which version of a dependency a library depends on (or a pattern to resolve one), but it's besides the point.
- ok123456 3y ago
  Rust is the issue here because it doesn't give you much of an option. And that option is the wrong one if you need to do an emergency upgrade of a particular library system-wide.
  - packetlost 3y ago
    It's really not, it's not hard to do a reverse search of [broken lib] <= depends on <= [rust application] and then rebuild everything that matches. You might have to rebuild more, but that's not really hard with modern build infrastructure. Not to mention if you have a Rust application that depends on C libraries, it already dynamically links on most platforms. You only need to rebuild if a Rust crate needs to be updated.
steveklabnik 3y ago
> imagined Cargo already has this information for every project it builds. That other systems do not is their issue, but it’s not a theoretical design.
- ok123456 3y ago
  So, I know that librustxz has been compromised. I'm Debian. I must dive into each rust binary I distribute as part of my system and inspect their Cargo.toml files. Then what? Do I fork each one, bump the version, hope it doesn't break everything, and then push an emergency release!??!
  - steveklabnik 3y ago
    > I must dive into each rust binary I distribute as part of my system and inspect their Cargo.toml A few things: 1. It'd be Cargo.lock 2. Debian, in particular, processes Cargo's output here and makes individual debs. So they've taken advantage of this to already know via their regular package manager tooling. 3. You wouldn't dive into and look through these by hand, you'd have it as a first-class concept. "Which packages use this package" should be table stakes for a package manager. > Then what? Do I fork each one, bump the version, hope it doesn't break everything, and then push an emergency release!??! The exact same thing you do in this current situation? It depends on what the issue is. Cargo isn't magic. The point is just that "which libraries does the binary depend on" isn't a problem with actual tooling. People already run tools like cargo-vet in CI to catch versions of packages that may have issues they care about.
    - ok123456 3y ago
      > The exact same thing you do in this current situation? It depends on what the issue is. Cargo isn't magic. False. In the current situation, you just release a new shared library that is used system-wide.
      - steveklabnik 3y ago
        Okay, so the analogous situation here is that you release a new version of the library, and rebuild. Done.