4 ms·

Disappointed there's no mention of vendoring. Anyone with _proper_ security concerns should cargo vendor by default. Last I looked supply chain attackers don't

Disappointed there's no mention of vendoring. Anyone with _proper_ security concerns should cargo vendor by default. Last I looked supply chain attackers don't respect semver and you are all one casual offhand cargo update away from catastrophe.

viccuad 4y ago
I don't think vendoring helps at all. People can't review all the dependencies' code. And recursively, for the dependencies of the dependencies. At some point, you delegate trust. What helps is having provenance information, signing and SBOM. One example. https://sigstore.dev https://sigstore.dev (vendor neutral effort from the Linux Foundation).
estebank 4y ago
For applications (as opposed to libraries), Cargo.lock fulfills the same function as vendoring, but lets cargo audit continue working as expected.
- Grimburger 4y ago
  To repeat: > one casual offhand cargo update away from catastrophe There is a scary amount of libraries who don't even bother specifying patch levels and will auto update everything upon request without question, even worse cargo doesn't make it explicit and as such version "1.0" is equivalent to "1.0.*" in the cargo manifest. Please refer to my previous comment about bad actors not respecting semver as much as many would love them to. `cargo audit` can be compromised by bad actors. `cargo update` also. If you have a security first application then always vendor, this isn't rust specific.
  - ilammy 4y ago
    Oh, so you trust "cargo build"? Why? Sure, "cargo update" will update the dependencies – that's what it's meant to do. The point of Cargo.lock is to ensure that all compilations use the same known set of versions, otherwise it's possible for developers to use one library and the users to use a different one. With Cargo.lock a new version of library won't be used without an explicit "cargo update".
liftm 4y ago
Not only does the guide not mention it, it seems to actively disagree with you: > The cargo-outdated tool must be used to check dependencies status. Then, each outdated dependency must be updated or the choice of the version must be justified. Especially for open source projects, there are also some other arguments against vendoring, see e.g. https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/ https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packag... If there's something that's missing mention, it is imho that the Cargo.lock files should be committed, and also included e.g. in docker builds. (I don't believe in offhanded "cargo update". And even if you did accidentally type it, nothing will be built/executed yet. There's ample opportunity to git restore Cargo.lock.)
kaba0 4y ago
Is there any plan to move to domain-qualified names? They seem to have prevented most of these attack in case of the java ecosystem.
- ilammy 4y ago
  Not on crates.io, they're pretty adamant about "no scoping" approach to naming. Scoping does not really solve injecting malicious code into the dependency tree in some update. Scoping is more of a defense against typosquatting via new crates. You can run your own crate registry if you're particularly concerned over what gets published on crates.io.

viccuad 4y ago

I don't think vendoring helps at all. People can't review all the dependencies' code. And recursively, for the dependencies of the dependencies. At some point, you delegate trust. What helps is having provenance information, signing and SBOM. One example. https://sigstore.dev https://sigstore.dev (vendor neutral effort from the Linux Foundation).

estebank 4y ago

For applications (as opposed to libraries), Cargo.lock fulfills the same function as vendoring, but lets cargo audit continue working as expected.

Grimburger 4y ago
To repeat: > one casual offhand cargo update away from catastrophe There is a scary amount of libraries who don't even bother specifying patch levels and will auto update everything upon request without question, even worse cargo doesn't make it explicit and as such version "1.0" is equivalent to "1.0.*" in the cargo manifest. Please refer to my previous comment about bad actors not respecting semver as much as many would love them to. `cargo audit` can be compromised by bad actors. `cargo update` also. If you have a security first application then always vendor, this isn't rust specific.
- ilammy 4y ago
  Oh, so you trust "cargo build"? Why? Sure, "cargo update" will update the dependencies – that's what it's meant to do. The point of Cargo.lock is to ensure that all compilations use the same known set of versions, otherwise it's possible for developers to use one library and the users to use a different one. With Cargo.lock a new version of library won't be used without an explicit "cargo update".

liftm 4y ago

Not only does the guide not mention it, it seems to actively disagree with you: > The cargo-outdated tool must be used to check dependencies status. Then, each outdated dependency must be updated or the choice of the version must be justified. Especially for open source projects, there are also some other arguments against vendoring, see e.g. https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/ https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packag... If there's something that's missing mention, it is imho that the Cargo.lock files should be committed, and also included e.g. in docker builds. (I don't believe in offhanded "cargo update". And even if you did accidentally type it, nothing will be built/executed yet. There's ample opportunity to git restore Cargo.lock.)

kaba0 4y ago

Is there any plan to move to domain-qualified names? They seem to have prevented most of these attack in case of the java ecosystem.

ilammy 4y ago
Not on crates.io, they're pretty adamant about "no scoping" approach to naming. Scoping does not really solve injecting malicious code into the dependency tree in some update. Scoping is more of a defense against typosquatting via new crates. You can run your own crate registry if you're particularly concerned over what gets published on crates.io.