Re:Remote Code Execution Vulnerability in Google They Are No...
by junon on Saturday April 15, 2023 @04:27PM
(#35584228)
Especially since a few users slurped up all of the interesting package names and refuse to give them up, despite many people complaining on GitHub. It's one of the huge warts of the cargo ecosystem it seems nobody on the rust team is willing to fix.
[ Parent
| on HN ]
Re:Remote Code Execution Vulnerability in Google They Are No...
by pclmulqdq on Saturday April 15, 2023 @05:03PM
(#35584502)
Who do you think slurped up the package names? It's not going to be random people.
Re:Remote Code Execution Vulnerability in Google They Are No...
by cornstalks on Saturday April 15, 2023 @06:37PM
(#35585337)
This punk: https://crates.io/users/swmon
They aren’t the only one, but they’re… prolific in this area. A list of squatted names is maintained here: https://github.com/dtolnay/squatternaut
Re:Remote Code Execution Vulnerability in Google They Are No...
by matheusmoreira on Saturday April 15, 2023 @05:47PM
(#35584886)
I think all packages should be namespaced per user. The language's core team could promote widely used packages to a "standard" namespace and give it a good name that way, thereby making it the "canonical" implementation of something.
Re:Remote Code Execution Vulnerability in Google They Are No...
by ilyt on Saturday April 15, 2023 @06:55PM
(#35585474)
I dunno how ecosystems keep making the same mistake.
All so someone can save few letters with typing dep name that one time they will be pulling it in into their project
Re:Remote Code Execution Vulnerability in Google They Are No...
by dgellow on Sunday April 16, 2023 @06:08AM
(#35588682)
The lack of namespacing in Rust is so weird. The discussion has been going for years, but it makes zero sense to me that after seeing issues npm and pypi faced during the past decade Rust is still pushing back against a more structured registry structure. Squatting will become more and more problematic the longer this flat registry approach persists.