4 ms·

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

by cntlzw 5y ago

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.

ChrisSD 5y ago
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.
junon 5y ago
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.
tetha 5y ago
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.
- deleted 5y ago
  [deleted]
- brabel 5y ago
  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.
  - kibwen 5y ago
    > 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?
    - brabel 5y ago
      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.
Ajedi32 5y ago
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.
- _tom_ 5y ago
  Analysis tools that show where large transitive dependencies could be avoided would help. Right now there is no feedback to encourage people to not have HUGE lists of dependencies. And for trivial reasons. This compounds the problem hugely. If you have three dependencies, verifying is feasible. If you have 3,000, it is not.
- ansible 5y ago
  I like all these ideas. > 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.
  - UncleMeat 5y ago
typicalbender 5y ago
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?
- brabel 5y ago
  Yes, they do that in Dart's pub [1]. 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 https://pub.dev/packages/darq/score) including up-to-date dependencies and result of static analysis. Dart is doing a lot of things right. [1] https://pub.dev/ https://pub.dev/ [2] https://dart.dev/tools/pub/publishing#verified-publisher https://dart.dev/tools/pub/publishing#verified-publisher
- Buttons840 5y ago
  Are there any tools that can scan my dependencies and point out names that are typos of older or more popular packages? Something like: you said "times", did you mean the older and more popular package "time"?

by cntlzw 5y ago

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.

ChrisSD 5y ago

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.

junon 5y ago

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.

tetha 5y ago

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.

deleted 5y ago
[deleted]
brabel 5y ago
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.
- kibwen 5y ago
  > 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?
  - brabel 5y ago
    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.

Ajedi32 5y ago

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.

_tom_ 5y ago
Analysis tools that show where large transitive dependencies could be avoided would help. Right now there is no feedback to encourage people to not have HUGE lists of dependencies. And for trivial reasons. This compounds the problem hugely. If you have three dependencies, verifying is feasible. If you have 3,000, it is not.
ansible 5y ago
I like all these ideas. > 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.
- UncleMeat 5y ago

typicalbender 5y ago

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?

brabel 5y ago
Yes, they do that in Dart's pub [1]. 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 https://pub.dev/packages/darq/score) including up-to-date dependencies and result of static analysis. Dart is doing a lot of things right. [1] https://pub.dev/ https://pub.dev/ [2] https://dart.dev/tools/pub/publishing#verified-publisher https://dart.dev/tools/pub/publishing#verified-publisher
Buttons840 5y ago
Are there any tools that can scan my dependencies and point out names that are typos of older or more popular packages? Something like: you said "times", did you mean the older and more popular package "time"?