Hacker News Reader

Comment by notaplumber | Hacker News Reader

> Is this really appropriate for a core system component to have this many dependencies?

Absolutely not. The entire OpenBSD base system can be built without an internet connection.

You can also build Rust and its ecosystem without an internet connection. It works the same way; you need to get a copy of everything first, but the build itself does not require the internet.

(This has been a hard constraint for effectively forever, because both Firefox and Linux distributions have this requirement.)

I understand that if you have all dependencies locally, you don't need to download more dependencies.

I understood NotAPlumber's remark as: openbsd has no third party dependencies. In other words: there is one party to trust, not 400.

If I misunderstood the BSD case, I'd love to hear it.

after you are done downloading all the source.

You can check that the source hasn’t been tampered with before starting the build, and know you’re building the right code base.

Builds that curl junk and use a dozen language specific package managers don’t have that property.

That is exactly the set of properties you get with Rust and Cargo: that the source hasn't been tampered with, and that you know you're building the right codebase. It would be deeply irresponsible to build a package management system without those properties.

True enough... but you still don't know what the dependencies do. E.g., one added ads. Another added use tracking. This could even be legitimately in line with the dependency's purpose.

Unless you're manually vetting all the code, 400 dependencies means trusting a lot of third parties.

Trusting a lot of third parties is almost as irresponsible as not bothering with checksumming, etc.

See npm and pip for examples. I suspect cargo will have its share of incidents over time, unless it is somehow curated by a small group that tests and maintains the packages, but if it is, then it’s comparable to apt for c/c++.

This is one of those things that's strictly true, but is kind of misleading because it doesn't capture the full picture. In particular, there is actually no guarantee that the source code you see on GitHub matches the source code you compile from crates.io. Now, most responsible maintainers tag each release and publish exactly that tag to crates.io. Which is good. But that's just a convention. There's nothing enforcing it.

If you want to actually review the source code, then you'd have to download the crate archive itself and review the code there. There is some tooling for this (notably, cargo-crev), but it's definitely not a normal part of development in the Rust open source ecosystem as it stands right now. For the most part, trust and reputation hold the system together. For example, imagine what would happen if someone found malicious code in one of my crates that I was duplicitous about (i.e., published it on crates.io but kept those code changes off of GitHub).

You're right.

I've heard from reliable sources that this is actively being worked on.

That assumes every user is a developer, expert in security assessment, knowledgeable in tricks like trusting trust, and all the languages used in the code base.

Reply on news.ycombinator.com