4 ms·
> Cargo allows for pinning dependencies If I pin dependencies, I am susceptible to not getting security updates. > because each is smaller and easier to verif
by whytevuhuni 2y ago
> Cargo allows for pinning dependencies
If I pin dependencies, I am susceptible to not getting security updates.
> because each is smaller and easier to verify
If I do not pin dependencies, then I am susceptible to crates.io shenanigans, where the artifacts uploaded to crates.io are not necessarily the code that was verified on github.
One of the 100 owners of my mini-dependencies will bump up their minor version by 0.0.1, push a rootkit/backdoor to crates.io (which was never on github), wait for a few users to retrieve that, then push another 0.0.1 update which removes it. Nobody will notice anything.
I can't believe I'm defending Boost here (I hate it) but at least it has some basic gatekeeping; one of their maintainers will have to approve that change, one of Debian's maintainers will have to pull that change, and I know the artifact I get was built on Debian's servers from the source code that is now set in stone forever, visible to everyone.
I don't get that with crates.io. Especially when each of those 100 mini-dependency owners can directly push code straight to my PC.
- timschmidt 2y ago> If I pin dependencies, I am susceptible to not getting security updates. True in every language. > If I do not pin dependencies, then I am susceptible to crates.io shenanigans I do think it would be nice to have a chain of trust associated with crates.io. Nothing precludes doing that, as far as I know. There's probably already a cargo plugin for it. > One of the 100 owners of my mini-dependencies will bump up their minor version by 0.0.1, push a rootkit/backdoor to crates.io This is a situation Cargo.lock can prevent. Thankfully crates.io is much easier to audit than millions of lines of decentralized [c/q/]make files, bash/zsh/csh scripts, etc.