255
this post was submitted on 16 May 2026
255 points (98.1% liked)
Programmer Humor
31487 readers
1032 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I guess one benefit is rust development often doesn't use bleeding edge version for everything, where you pull the entirety of crates.io through your machine when you open your IDE. From what I've seen most projects use == versions and lock files.
I don't know enough about rust though. Could an attacker change historical crate versions to a payload and then cargo pulls them because they changed? Or will cargo only pull an update if you change to a different version on your machine?
You can't overwrite previously published versions.
Application projects are recommended to check-in the
Cargo.lockwhich pins dependency versions but you can always just runcargo updateat any time which automatically upgrades all dependencies to the newest version allowed by theCargo.toml.Some projects get around this by pinning the dependency in the
Cargo.toml(using=) or by vendoring all their dependencies, which is a huge pain in the ass.Cargo does not respect lockfiles by default, AFAIK. You need to explicitly pass the --locked flag.
When you
cargo installa binary, it ignores lockfiles. If you clone a project and build it, it respects theCargo.lockthat was checked in.That sounds better and worse. An attack could persist past one specific version without anyone noticing for a bit.