5 ms·

This sounds a lot like cargo-crev but without off-line cryptographic signatures, a significant downgrade in my view. Edit: Yep: https://mozilla.github.io/cargo

by hda2 4y ago

This sounds a lot like cargo-crev but without off-line cryptographic signatures, a significant downgrade in my view. Edit: Yep: https://mozilla.github.io/cargo-vet/design-choice-faq.html#how-does-this-relate-to-cargo-crev https://mozilla.github.io/cargo-vet/design-choice-faq.html#h... None of the reasons given by Mozilla seem to justify the downgrade in security, especially since most can be worked around with crev which already employs secure and well-tested authentication schemes. What also makes this situation peculiar to me is that it's being immediately rushed into Cargo proper instead of the usual way these tools are handled by the Cargo team (i.e. allowing multiple ideas to compete as third-party tools and maybe choosing one once a winner is clear). I understand the recent string of security issues might have played a role here, but I wouldn't expect their reaction to be steamrolling an inferior version of crev as a builtin tool. I would really like to know what happened here. Disclosure: I use neither tool, but I'm very interested in the security and health of the Rust ecosystem.

LegionMammal978 4y ago
> What also makes this situation peculiar to me is that it's being immediately rushed into Cargo proper instead of the usual way these tools are handled by the Cargo team (i.e. allowing multiple ideas to compete as third-party tools and maybe choosing one once a winner is clear). This tool isn't being pushed into Cargo proper, and I doubt it will be any time soon. Instead, it is a third-party crate called "cargo-vet". If an executable named "cargo-whatever" is in the search path, Cargo can invoke it as a subcommand "cargo whatever". See Cargo's docs for more info: https://doc.rust-lang.org/cargo/reference/external-tools.html#custom-subcommands https://doc.rust-lang.org/cargo/reference/external-tools.htm...
- cozzyd 4y ago
  hopefully nobody adds a cargo-buidl package then!
  - nindalf 4y ago
    Why would a user install a cargo-buidl package when cargo build already works? Typosquatting is definitely an issue, but not in this specific case.
    - kzrdude 4y ago
      The binary can be named that without the package being named so, so it seems it could happen
      - dmytrish 4y ago
        If an intruder can rename files in your $PATH, the defense is already broken (e.g. they could do the same with any of .bashrc, .profile, anything in .local/bin and many, many other places). If a program can run seemingly innocent programs like less or sed, it already can run arbitrary commands. Security story of developing on Linux is basically non-existent unless you do everything on a remote machine or at least in a container (and, oh irony: direct access from your user to the Docker daemon basically means having root for that user).
        deleted 4y ago
        [deleted]
        kzrdude 4y ago
        Well I was thinking that "cargo install foo" can already install cargo-buidl in your path by innocent means i.e. no Rust build script. But with build scripts (build.rs) any crate indeed has arbitrary code execution at build time, so they can't be trusted, like you imply. However, sandboxing might be coming for build scripts, and when that's done, the typo attack is still there (package "foo" installing cargo-buidl).
    - cozzyd 4y ago
      right, but cargo-buidl could be installed as part of a different package that also provides a more useful-sounding binary, no?
  - royjacobs 4y ago
    You need to explicitly install these tools, so you can't "accidentally" invoke cargo-buidl from a transitive dependency or anything. It's not like a tool like npx which will allow you to invoke code in arbitrary packages.
    - cozzyd 4y ago
      yeah it's great that "cargo buidl" doesn't automatically try to download and install cargo-buidl but if cargo-buidl somehow ends up in your $PATH (perhaps installed as a side effect of another package or even some other package manager like pip) then it will run. Though I guess someone could also just as easily put a malicious cargo in your $PATH and that will work in most cases, depending on precedence...
rslabbert 4y ago
Since the audits are designed to be used at a per project level and contributed directly into the VCS repo (allowing you to using git signing for example) I don't quite understand what additional off-line cryptographic signatures are required here (considering that Cargo's lockfiles already contain a hash of the crate which would prevent the project from getting an altered version of a crate accidentally and that SHA validation is being considered as part of vet as well https://github.com/mozilla/cargo-vet/issues/116 https://github.com/mozilla/cargo-vet/issues/116).
pornel 4y ago
That's fine. The biggest problem right now is getting people actually review their dependencies. If cargo-vet can make that easier by removing hassle of signatures and WoT, it's still a huge benefit to the community. It's possible to make cargo-vet <> cargo-crev export tools.

by hda2 4y ago

LegionMammal978 4y ago

> What also makes this situation peculiar to me is that it's being immediately rushed into Cargo proper instead of the usual way these tools are handled by the Cargo team (i.e. allowing multiple ideas to compete as third-party tools and maybe choosing one once a winner is clear). This tool isn't being pushed into Cargo proper, and I doubt it will be any time soon. Instead, it is a third-party crate called "cargo-vet". If an executable named "cargo-whatever" is in the search path, Cargo can invoke it as a subcommand "cargo whatever". See Cargo's docs for more info: https://doc.rust-lang.org/cargo/reference/external-tools.html#custom-subcommands https://doc.rust-lang.org/cargo/reference/external-tools.htm...

cozzyd 4y ago
hopefully nobody adds a cargo-buidl package then!
- nindalf 4y ago
  Why would a user install a cargo-buidl package when cargo build already works? Typosquatting is definitely an issue, but not in this specific case.
  - kzrdude 4y ago
    The binary can be named that without the package being named so, so it seems it could happen
    - dmytrish 4y ago
      If an intruder can rename files in your $PATH, the defense is already broken (e.g. they could do the same with any of .bashrc, .profile, anything in .local/bin and many, many other places). If a program can run seemingly innocent programs like less or sed, it already can run arbitrary commands. Security story of developing on Linux is basically non-existent unless you do everything on a remote machine or at least in a container (and, oh irony: direct access from your user to the Docker daemon basically means having root for that user).
      - deleted 4y ago
        [deleted]
      - kzrdude 4y ago
        Well I was thinking that "cargo install foo" can already install cargo-buidl in your path by innocent means i.e. no Rust build script. But with build scripts (build.rs) any crate indeed has arbitrary code execution at build time, so they can't be trusted, like you imply. However, sandboxing might be coming for build scripts, and when that's done, the typo attack is still there (package "foo" installing cargo-buidl).
  - cozzyd 4y ago
    right, but cargo-buidl could be installed as part of a different package that also provides a more useful-sounding binary, no?
- royjacobs 4y ago
  You need to explicitly install these tools, so you can't "accidentally" invoke cargo-buidl from a transitive dependency or anything. It's not like a tool like npx which will allow you to invoke code in arbitrary packages.
  - cozzyd 4y ago
    yeah it's great that "cargo buidl" doesn't automatically try to download and install cargo-buidl but if cargo-buidl somehow ends up in your $PATH (perhaps installed as a side effect of another package or even some other package manager like pip) then it will run. Though I guess someone could also just as easily put a malicious cargo in your $PATH and that will work in most cases, depending on precedence...

rslabbert 4y ago

Since the audits are designed to be used at a per project level and contributed directly into the VCS repo (allowing you to using git signing for example) I don't quite understand what additional off-line cryptographic signatures are required here (considering that Cargo's lockfiles already contain a hash of the crate which would prevent the project from getting an altered version of a crate accidentally and that SHA validation is being considered as part of vet as well https://github.com/mozilla/cargo-vet/issues/116 https://github.com/mozilla/cargo-vet/issues/116).

pornel 4y ago

That's fine. The biggest problem right now is getting people actually review their dependencies. If cargo-vet can make that easier by removing hassle of signatures and WoT, it's still a huge benefit to the community. It's possible to make cargo-vet <> cargo-crev export tools.