News for hackers. Stuff that matters.
Re:Making Rust supply chain attacks harder with Cackle by mirashii on Friday October 13, 2023 @01:41PM (#37873330)
The notion that one should always pin their dependency version falls apart when considering that package managers like cargo when considering libraries. Libraries hard pinning dependencies causes a world of trouble.

This is exactly why cargo uses a lock file that does pin your dependencies as described for binary crates, but does not use the same mechanism for libraries. https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-hav...

Re:Making Rust supply chain attacks harder with Cackle by finnh on Friday October 13, 2023 @01:48PM (#37873401)
Good point, diamond-pattern dependencies can get hellish. In the past, rather than deal with shadowing etc, I've resorted to choosing versions of my major dependencies that use the same version of their underlying dependency (for example, sync my GRPC lib with other HTTP client libs so they all use the same version of Netty - this is in the Java world).
Re:Making Rust supply chain attacks harder with Cackle by belinder on Friday October 13, 2023 @01:58PM (#37873511)
Wouldn't the library dependency hierarchy have been figured out during development in order to get it to a state that can compile? I'm assuming if you're pinning a dependency you already have something that compiles
Re:Making Rust supply chain attacks harder with Cackle by paholg on Friday October 13, 2023 @03:27PM (#37874524)
Let's say crate B depends on crate A with a pinned dependency, and uses one of its types in a public interface.

Crate C depends on them both. It now can't bring in updates to A until B does, and when B updates that's a breaking change, so it better bump its major version.

Take a look at this trick, for example, for foundational crates updating their major version: https://github.com/dtolnay/semver-trick

Now imagine that being an issue every single patch update.

Re:Making Rust supply chain attacks harder with Cackle by belinder on Friday October 13, 2023 @04:35PM (#37875321)
Yeah I see what you mean, it's not so much about the first time it's deployed but for future updates where you want to update one dependency but another one requires it to stay the way it is
Re:Making Rust supply chain attacks harder with Cackle by random_ on Friday October 13, 2023 @04:32PM (#37875292)
Quite interesting. That doesn't seems like a complete falling apart but rather a (unintentional?) attempt of best of worlds since once set your dependencies on your binary, they will be pinned until you manually run a cargo update.

Granted that the supply chain attack defense would fall on the hands of the users of the library. Unless the library writer aggressively pins of dependencies on the Cargo.toml (not the default semver action), problematic, but at least Cargo allows multiple versions of dependencies on a program, on Python for instance this is much complicated scenario (but still the smallest of the dependencies problems there).

Re:Making Rust supply chain attacks harder with Cackle by steveklabnik on Friday October 13, 2023 @04:59PM (#37875552)
This behavior as very intentional, patterned after Bundler.
Re:Making Rust supply chain attacks harder with Cackle by epage on Friday October 13, 2023 @06:03PM (#37876116)
That guidance has changed and will hit stable for 1.74 (5 weeks).

For the new guidance: https://doc.rust-lang.org/nightly/cargo/faq.html#why-have-ca...

See also https://blog.rust-lang.org/2023/08/29/committing-lockfiles.h...