3 ms·

You're not wrong about arbitrary code execution. It's just that your statement applies to most of the packages on any linux distribution, Autotools and Cmake i

You're not wrong about arbitrary code execution. It's just that your statement applies to most of the packages on any linux distribution, Autotools and Cmake included, regardless of language. Many moreso than Rust due to the aforementioned features of Cargo and build.rs not requiring me to be an expert in a second language just to audit it.

bonzini 3y ago
Packages in a Linux distro are not built on my machine, they are built by the distro in a sandbox. Every time I type "cargo build" I am potentially running arbitrary code downloaded from the internet. Every time I type "make" in an Autotools program only my code runs. > not requiring me to be an expert in another language just to audit it. Do you do that every time your Cargo.lock changes?
- timschmidt 3y ago
  > Every time I type "make" in an Autotools program only my code runs. Says who? Make is just as good at calling arbitrary code as Cargo. Including code that reaches out over the network. Have you audited every single makefile to ensure that isn't the case?
  - bonzini 3y ago
    I am talking about my makefiles. They don't automatically build dependencies that I have no control on. Whereas building my crate can run code locally that no one has ever audited.
    - timschmidt 3y ago
      So... you're complaining about what could happen in a Rust build if you include a library without examining that library first? How do you think that is different from doing the same in any other language?
      - bonzini 3y ago
        The difference is that in another language the build step is delegated to someone else who has packaged the code, and every version has presumably gone through some kind of audit. With Rust I have no idea what new transitive dependencies could be included any time I update one of my dependencies, and what code could be triggered just by building my program without even running it. Again, we're not talking about the dependencies that I choose, but the whole transitive closure of dependencies, including the most low-level. Did you examine serde the first time you used a dependency that used it? serde did have in the past a slightly sketchy case of using a pre-built binary. Or the whole dependency tree of Bevy? I mean, Rust has many advantages but the cargo supply chain story is an absolute disaster---not that it's alone, pypi or nodejs or Ruby gems are the same.
        timschmidt 3y ago
        > The difference is that in another language the build step is delegated to someone else who has packaged the code Fedora packages a large number of Rust libraries, just as you describe. Nothing prevents you from using the packaged libraries if you prefer them. You may find helpful information here: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ https://docs.fedoraproject.org/en-US/packaging-guidelines/Ru...
        bonzini 3y ago
        > Nothing prevents you from using the packaged libraries if you prefer them Nothing except, in no particular order: 1) only having one version of crates 2) mismatched features 3) new transitive dependencies that can be introduced at any time without any warning 4) only supporting one version of rust 5) packages being noarch and basically glorified distro-wide vendoring—so their build.rs code is still run on your machine at cargo build time
        timschmidt 3y ago
        > 1) only having one version of crates Same as any other library provided by the distribution in any other language. > 2) mismatched features Same as any other library provided by the distribution in any other language. > 3) new transitive dependencies that can be introduced at any time without any warning Not in packaged Rust libraries in Fedora, at least. Please read the aforementioned link. > 4) only supporting one version of rust Same as any other library provided by the distribution in any other language. > 5) packages being noarch and basically glorified distro-wide vendoring Packages containing only source is a consequence of the Rust ABI still stabilizing, see: https://github.com/rust-lang/rust/pull/105586 https://github.com/rust-lang/rust/pull/105586 After ABI stabilization, Rust libraries will be first class like any other language.
- fragmede 3y ago
  seems trivial for a configure script to call curl/wget somewhere in the depths of it, no?
  - timschmidt 3y ago
    Exactly. And at least Cargo will refuse to download a crate which has been yanked. So any crate which has been discovered to be compromised can be yanked, preventing further damage even when someone has already downloaded something which depends on it. Building packages with up-to-date dependencies is also vastly preferable to building against ancient copies of libraries vendored into a codebase at some point in the past, a situation I see far too often in C/C++ codebases.
  - Hackbraten 3y ago
    Debian’s rules files often deliberately sinkhole the entire network during the build. It’s not the worst idea.
    - fragmede 3y ago
      I wonder if you could do it inside the config script without the network.

bonzini 3y ago

Packages in a Linux distro are not built on my machine, they are built by the distro in a sandbox. Every time I type "cargo build" I am potentially running arbitrary code downloaded from the internet. Every time I type "make" in an Autotools program only my code runs. > not requiring me to be an expert in another language just to audit it. Do you do that every time your Cargo.lock changes?

timschmidt 3y ago
> Every time I type "make" in an Autotools program only my code runs. Says who? Make is just as good at calling arbitrary code as Cargo. Including code that reaches out over the network. Have you audited every single makefile to ensure that isn't the case?
- bonzini 3y ago
  I am talking about my makefiles. They don't automatically build dependencies that I have no control on. Whereas building my crate can run code locally that no one has ever audited.
  - timschmidt 3y ago
    So... you're complaining about what could happen in a Rust build if you include a library without examining that library first? How do you think that is different from doing the same in any other language?
    - bonzini 3y ago
      The difference is that in another language the build step is delegated to someone else who has packaged the code, and every version has presumably gone through some kind of audit. With Rust I have no idea what new transitive dependencies could be included any time I update one of my dependencies, and what code could be triggered just by building my program without even running it. Again, we're not talking about the dependencies that I choose, but the whole transitive closure of dependencies, including the most low-level. Did you examine serde the first time you used a dependency that used it? serde did have in the past a slightly sketchy case of using a pre-built binary. Or the whole dependency tree of Bevy? I mean, Rust has many advantages but the cargo supply chain story is an absolute disaster---not that it's alone, pypi or nodejs or Ruby gems are the same.
      - timschmidt 3y ago
        > The difference is that in another language the build step is delegated to someone else who has packaged the code Fedora packages a large number of Rust libraries, just as you describe. Nothing prevents you from using the packaged libraries if you prefer them. You may find helpful information here: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ https://docs.fedoraproject.org/en-US/packaging-guidelines/Ru...
        bonzini 3y ago
        > Nothing prevents you from using the packaged libraries if you prefer them Nothing except, in no particular order: 1) only having one version of crates 2) mismatched features 3) new transitive dependencies that can be introduced at any time without any warning 4) only supporting one version of rust 5) packages being noarch and basically glorified distro-wide vendoring—so their build.rs code is still run on your machine at cargo build time
        timschmidt 3y ago
        > 1) only having one version of crates Same as any other library provided by the distribution in any other language. > 2) mismatched features Same as any other library provided by the distribution in any other language. > 3) new transitive dependencies that can be introduced at any time without any warning Not in packaged Rust libraries in Fedora, at least. Please read the aforementioned link. > 4) only supporting one version of rust Same as any other library provided by the distribution in any other language. > 5) packages being noarch and basically glorified distro-wide vendoring Packages containing only source is a consequence of the Rust ABI still stabilizing, see: https://github.com/rust-lang/rust/pull/105586 https://github.com/rust-lang/rust/pull/105586 After ABI stabilization, Rust libraries will be first class like any other language.
fragmede 3y ago
seems trivial for a configure script to call curl/wget somewhere in the depths of it, no?
- timschmidt 3y ago
  Exactly. And at least Cargo will refuse to download a crate which has been yanked. So any crate which has been discovered to be compromised can be yanked, preventing further damage even when someone has already downloaded something which depends on it. Building packages with up-to-date dependencies is also vastly preferable to building against ancient copies of libraries vendored into a codebase at some point in the past, a situation I see far too often in C/C++ codebases.
- Hackbraten 3y ago
  Debian’s rules files often deliberately sinkhole the entire network during the build. It’s not the worst idea.
  - fragmede 3y ago
    I wonder if you could do it inside the config script without the network.