How do rust crates compare with something like maven or npm? It looks like some issues for example Typosquatting can be done in all of these dependency managers.
Yep, supply chain attacks are a near-universal problem with programing language package managers.
I think there's a lot of room for improvement here. Some good low-hanging fruit IMO would be to:
1. Take steps to make package source code easier to review.
1.1. When applicable, encourage verified builds to ensure package source matches the uploaded package.
1.2. Display the source code on the package manager website, and display a warning next to any links to external source repositories when it can't be verified that the package's source matches what's in that repo.
1.3. Build systems for crowdsourcing review of package source code. Even if I don't trust the package author, if someone I _do_ trust has already reviewed the code then it's probably okay to install.
2. Make package managers expose more information about who exactly you're trusting when you choose to install a particular package.
2.1. List any new authors you're adding to your dependency chain when you install a package.
2.2. Warn when package ownership changes (e.g. new version is signed by a different author than the old one).
Long-term, maybe some kind of sandbox for dependencies could make sense. Lots of dependencies don't need disk or network access. Denying them that would certainly limit the amount of damage they can do if they are compromised, provided the host language makes that level of isolation feasible.
> Long-term, maybe some kind of sandbox for dependencies could make sense. Lots of dependencies don't need disk or network access.
Just like with Android permissions, we could audit the crate sources to list out what functions it uses (out of the standard library or where ever) and provide an indication of that this particular crate is capable of.
For what it's worth, this Principle Of Least Authority / object-capability model is being attempted in the JavaScript ecosystem with SES (Secure ECMAScript).
This is a strategy, but it typically falls apart against clever attackers who are targeting you specifically. Hackers have been performing return-to-libc attacks forever where they don't actually get to write any code at all, just sequence code that already exists in your binary.
Java also tried this in a slightly more rigorous manner with the SecurityManager and that just ended up being a botch.
Yeah that's why I said it really depends on the host language to make such sandboxing feasible. If you're using a language that lets code write arbitrary data to arbitrary memory locations, implementing a secure sandbox is going to be pretty tricky.
Maven Central is somewhat resilient against this. In the java world, an artifact is identified by a group-id, an artifact-id and a version, and some technical stuff. The group id is a reversed domain, like org.springframework.
If you want to upload artifacts with the group id "org.springframework", you first have to demonstrate that you own springframework.org via a challenge, usually a TXT record or some other possibilities for github group-ids and such.
It's not entirely bulletproof, because you could squat group-ids "org.spring" or "org.spring.framework" (if you can get that domain). However, once a developer knows the correct group id is "org.springframework", you need additional compromises to upload an artifact "backdoor" there.
Edit - and as I'm currently seeing, PGP signatures are also required by now.
It's a hell of a lot harder to squat namespaces as you need to either spoof or steal or buy one domain per namespace, which is not trivial.
Maven Central has require PGP signatures since the beginning as far as I know! In the olden days, it didn't use HTTPS though (which has been fixed for several years now), so unless you validated the signatures and kept track of the PGP keys, you could still run into trouble.
> It's a hell of a lot harder to squat namespaces as you need to either spoof or steal or buy one domain per namespace, which is not trivial.
This introduces a different security wrinkle, as domain names need to be continually renewed. What does Maven do to prevent unauthorized transfer of namespace ownership when a domain lapses?
That seems to be a very unusual case, but because Maven uses PGP keys, the domain owner would need to ALSO transfer their own PGP keys to the new domain owner, otherwise lib consumers wouldn't automatically (at least) trust their releases under that domain name.
I haven't thought this through at all but are you aware of any package repositories that do something like levenshtein distance between package names maybe combined with a heuristic on common mistyped characters to not allow typosquatting?
They also have the concept of verified publishers[2], which is pretty neat (similar to Maven Central), and keep track of a score for each package (e.g. https://pub.dev/packages/darq/score) including up-to-date dependencies and result of static analysis.
These do all seem to be things that apply to most package managers of this kind. So it would be good if Rust could find solutions that can be applied more broadly.
npm has some guards for typosquatting. They're annoying when you run into them but I appreciate that they're there. I have no idea how effective or extensive they are, though.
