Hacker News Reader

Comment by kibwen | Hacker News Reader

I still don't understand what alternative people are arguing in favor of. When I think of those "best in class" libraries like regex, serde, etc, those are multiple crates that are developed by the same teams. Having one massive crate or one hundred tiny crates is irrelevant here, because if they're all developed by the same contributors it does not increase your trusted computing base.

View on HN

I do think that there's some work that can be done to improve reporting on our side: cargo should be able to report not just "how many crates are in the dep tree" but rather "how many owners am I depending on" and "how many repositories am I depending on". For example, I just noticed that there's no way to see in crates.io other crates that live in the same repository, like it does per owner, even though it has that information available.

> "how many owners am I depending on"

Yes, knowing that would be helpful!

Is there a way to whitelist owners/publishers in Cargo?

No tool for that exists afaik, but all the pieces to make it are there.

There is `cargo-deny` that handles some enforcement: https://github.com/EmbarkStudios/cargo-deny. Doesn't handle authors, but I suspect it's easy to add?

There is really just a handful of crates that nearly often get pulled in and probably like 5 authors across them.

Supply chain harderning is pretty easy in rust: caro-deny, cargo-suply-chain, cargo-crev, cargo-vet, cargo-{s}bom and probably a few more I can't remember.

Cargo currently has `cargo tree`, which prints out a dependency tree. There's an extension to cargo which also shows how many people have the ability to push to your dependencies, titled `cargo-supply-chain`.

https://github.com/rust-secure-code/cargo-supply-chain/

Yeh, this would be great. I'd also love to see the ability to publish multiple library crates as a single package.

I'd settle for most dependencies not having any dependencies at all; at a minimum making a serious effort to only add dependencies that really pull their own weight.

This starts from explaining outright which dependencies they have and why.

It's not so much direct dependencies that bother me: it's an exponential explosion of transitive dependencies.

Also, seeing an “end product” with dozens of dependencies doesn't bother me much; a library does.

Is each web framework expected to reimplement regex, path matching and HTTP protocol logic themselves?

Should every physics/ML/etc library have to write their own array abstractions and operators? If every networking library had to write and ship their own async executor logic, I can safely posit that would be about 100x worse than it is now.

The alternative to “zero dependencies” isn’t full “JS/NPM-dumpster-fire”.

Reply on news.ycombinator.com