3 ms·

> There is no mediation of any kind between when a new library/version is published and when it is consumed. > A simple time delay will allow egregious malware

> There is no mediation of any kind between when a new library/version is published and when it is consumed. > A simple time delay will allow egregious malware like malicious build.rs scripts to be caught, whether that’s the super-long Debian stable cycle or even the several days required to migrate from unstable to testing. Normal cargo + crates.io usage has the same property via the existence of lockfiles. For most people that care about stability, this will provide a natural delay (which you can also see in crates.io download graphs) to consuming the latest version. ----- The other points brought up in the article are definitely valid, but if that's the main strategy of defense you are looking for, you might already have it.

dathinab 3y ago
> if that's the main strategy of defense mostly, there can be a small attack gap when adding new dependencies to the project and at the specific point in time when you run `update` through you can also pin versions in `Cargo.toml` and then review any updates, maybe except for a few highly trusted sources (it's a bit annoying and costly (time wise) but viable) Through trying to vendor things, especially with Debian, seems like a horrible solution. And there is a lot of precedence for this causing tons of headaches, wrong bug reports and similar for developer (== time loss == time is money so we could probably be speaking about multiple millions of monetary damages). Through I have been thinking for a while that it could be interesting to have a partial crates.io "proxy" which only contains and updates crates which have gotten a "basic screening" in all of their code and dependencies probably with some tool assistance this might not find bugs but it should find many forms of supply chain attacks. Through given that this is costly to provide it probably would not be a free service.
- hobofan 3y ago
  > there can be a small attack gap when adding new dependencies to the project Most package managers will keep the versions of transitive dependencies as unchanged as possible when adding a new direct dependency. Of course if the only solution to satisfy the dependencies of the new direct dependency is to upgrade a transitive dependency, that will be done. (I've seen a lot of people treat dependency additions as completely unpredictable operations that regenerate the whole lockfile in the past, which is why I wanted to clear this up.)
frankjr 3y ago
> Normal cargo + crates.io usage has the same property via the existence of lockfiles. For most people that care about stability, this will provide a natural delay (which you can also see in crates.io download graphs) to consuming the latest version. Be aware however that lock files are ignored by default. You need to specify "--locked" if you want Cargo to use the "locked" versions from Cargo.lock. > By default, the Cargo.lock file that is included with the package will be ignored. This means that Cargo will recompute which versions of dependencies to use, possibly using newer versions that have been released since the package was published. https://doc.rust-lang.org/cargo/commands/cargo-install.html#dealing-with-the-lockfile https://doc.rust-lang.org/cargo/commands/cargo-install.html#...
- hobofan 3y ago
  This only applies to the `cargo install` command to install binaries from crates.io. If you work in a repository on your own project and use basically any other cargo command (e.g. `cargo build`, `cargo run`), the lock file is of course taken into account (otherwise it would be near-useless).
  - frankjr 3y ago
    Right but that's not the only use case for `cargo install`. You can also use it to install binaries system wide from cloned repositories (`cargo install --path .`). I use this often for small utilities (for which I have no intention of publishing to crates.io) or when testing before packaging for Arch.
- MrJohz 3y ago
  This is installing binaries from crates.io directly (i.e. running "cargo install ripgrep" instead of "sudo apt..." or whatever equivalent). Admittedly, this is often a suggested installation method for some built-in-Rust tools, but it's usually an option of last resort, and most people should be using their usual package manager for this. Cargo does respect the package lock file when building a project from source (i.e. when you checkout a project, and run `cargo build` in that project directory). This happens, for example, when running builds in CI, or preparing a new release for each individual package manager.

dathinab 3y ago

> if that's the main strategy of defense mostly, there can be a small attack gap when adding new dependencies to the project and at the specific point in time when you run `update` through you can also pin versions in `Cargo.toml` and then review any updates, maybe except for a few highly trusted sources (it's a bit annoying and costly (time wise) but viable) Through trying to vendor things, especially with Debian, seems like a horrible solution. And there is a lot of precedence for this causing tons of headaches, wrong bug reports and similar for developer (== time loss == time is money so we could probably be speaking about multiple millions of monetary damages). Through I have been thinking for a while that it could be interesting to have a partial crates.io "proxy" which only contains and updates crates which have gotten a "basic screening" in all of their code and dependencies probably with some tool assistance this might not find bugs but it should find many forms of supply chain attacks. Through given that this is costly to provide it probably would not be a free service.

hobofan 3y ago
> there can be a small attack gap when adding new dependencies to the project Most package managers will keep the versions of transitive dependencies as unchanged as possible when adding a new direct dependency. Of course if the only solution to satisfy the dependencies of the new direct dependency is to upgrade a transitive dependency, that will be done. (I've seen a lot of people treat dependency additions as completely unpredictable operations that regenerate the whole lockfile in the past, which is why I wanted to clear this up.)

frankjr 3y ago

> Normal cargo + crates.io usage has the same property via the existence of lockfiles. For most people that care about stability, this will provide a natural delay (which you can also see in crates.io download graphs) to consuming the latest version. Be aware however that lock files are ignored by default. You need to specify "--locked" if you want Cargo to use the "locked" versions from Cargo.lock. > By default, the Cargo.lock file that is included with the package will be ignored. This means that Cargo will recompute which versions of dependencies to use, possibly using newer versions that have been released since the package was published. https://doc.rust-lang.org/cargo/commands/cargo-install.html#dealing-with-the-lockfile https://doc.rust-lang.org/cargo/commands/cargo-install.html#...

hobofan 3y ago
This only applies to the `cargo install` command to install binaries from crates.io. If you work in a repository on your own project and use basically any other cargo command (e.g. `cargo build`, `cargo run`), the lock file is of course taken into account (otherwise it would be near-useless).
- frankjr 3y ago
  Right but that's not the only use case for `cargo install`. You can also use it to install binaries system wide from cloned repositories (`cargo install --path .`). I use this often for small utilities (for which I have no intention of publishing to crates.io) or when testing before packaging for Arch.
MrJohz 3y ago
This is installing binaries from crates.io directly (i.e. running "cargo install ripgrep" instead of "sudo apt..." or whatever equivalent). Admittedly, this is often a suggested installation method for some built-in-Rust tools, but it's usually an option of last resort, and most people should be using their usual package manager for this. Cargo does respect the package lock file when building a project from source (i.e. when you checkout a project, and run `cargo build` in that project directory). This happens, for example, when running builds in CI, or preparing a new release for each individual package manager.