55
Could rust do with a crates.io alternative?
(programming.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 28 Oct 2023
55 points (92.3% liked)
Rust
5960 readers
4 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
I know a lot of people want namespaces. And I think it would be nice for a bigger project to have an obvious way to show which packages are part of this big project, and which are not. For example the different serde serialization formats would not need to be listed in the docs, but simply be present in one single serde-formats namespaces.
It it does fuck all for type squatting. Sure, now I'm safe from getting malicious code by doing tokio/tokiu-http, but tokiu/tokio-http can still be malicious!
The only solution to type squatting would be a checksum. So instead of adding Tokio to your toml file you'd have to add e.g. tokio-fld, with the fld part being some kind of check that is derived from the name. Similar to a hash, all names that are similar to tokio would get a wildly different suffix.
You are indeed correct. I hadn't considered that!
The checksum idea might work 🤔 That definitely could be possible with the new registry.
I think you could get it with a signature, just like with Linux repos. Basically, the org would sign the metadata so you know it came from that org's key.
That way you'd need both a malicious name and access to the key. You don't need the suffix here, just a section in the toml that lets you list keys per org, and if it changes, you'd get prompted to update it.
I don't think changing is the problem, incorrect initial entry is the problem. Linux has centralized package maintainers, cargo does not (or am I wrong?)
Or do you mean that adding a namespace would require a key and then all crates in that namespace are unlocked? Then only the initial cargo add would be dangerous, all subsequent ones in the same namespace would not require manual confirmation.
Yes, I'm saying that adding a namespace would require a key, and all releases would be signed with that key. That works similarly to installing a separate repo in a Linux distro, you'd import the key and mark it as trusted, and then signatures would be verified for each download.
So yes, only the initial cargo add would be "dangerous," and there would be a prompt for the user to verify that they have the right key (which they could verify on the project homepage).