This only seems to be an issue for languages where packages reside in a global namespace, like Python, Rust etc. I think most languages these days are a bit smarter and avoid this beginner mistake (for various reasons).
Typosquatting programming language package managers
51–60 of 148 posts
Re: Typosquatting programming language package managers
#52We've gotten flack from package developers submitting new packages to Package Control [0] because all additions to the default channel are hand reviewed. Part of this process is to prevent accidentally close package names, to try and encourage collaboration and to encourage developers to actually explain what their package does and how to use it. My hope is to be automating a large amount of the review in the next fe…
Thanks for keeping Package Control high quality, I know it's highly appreciated :-)
Re: Typosquatting programming language package managers
#53I'm a fan of the approach of personally submitting projects to the repository maintainer (e.g. through GitHub issues), and having the maintainer personally approve them. It does raise the barrier to entry, but it would prevent typosquatting and regular namesquatting. EDIT: Does any major package manager provide a "did you mean" functionality, offering a list of actual package names similar to what you typed?
Or someone needs to approve suspiciously named packages.
Re: Typosquatting programming language package managers
#54This only seems to be an issue for languages where packages reside in a global namespace, like Python, Rust etc. I think most languages these days are a bit smarter and avoid this beginner mistake (for various reasons).
Re: Typosquatting programming language package managers
#55We've gotten flack from package developers submitting new packages to Package Control [0] because all additions to the default channel are hand reviewed. Part of this process is to prevent accidentally close package names, to try and encourage collaboration and to encourage developers to actually explain what their package does and how to use it. My hope is to be automating a large amount of the review in the next fe…
Re: Typosquatting programming language package managers
#56Earlier quoted context omitted.
Might it work to mandate that the name of an uploaded package have a minimum levenshtein distance (or similar calculation) from the names of all the existing packages? Then you wouldn't have to worry about maintaining a blacklist.
That would mean that, for example on crates.io, you couldn't create a `libm`, because `libc` is already very popular. I don't think that works.
Re: Typosquatting programming language package managers
#57Did anyone else find it surprising the the number of total requests (45334) is so much higher than the number of unique total requests (17289)? It is more than twice the number of unique requests! Possible explainations: * Perhaps many of those are automated build systems, which would also explain the high number of systems with admin access (for example, if you use travis without docker, every build runs in a clean…
Re: Typosquatting programming language package managers
#58We've gotten flack from package developers submitting new packages to Package Control [0] because all additions to the default channel are hand reviewed. Part of this process is to prevent accidentally close package names, to try and encourage collaboration and to encourage developers to actually explain what their package does and how to use it. My hope is to be automating a large amount of the review in the next fe…
Re: Typosquatting programming language package managers
#59This only seems to be an issue for languages where packages reside in a global namespace, like Python, Rust etc. I think most languages these days are a bit smarter and avoid this beginner mistake (for various reasons).
Ruby and JS package managers are un-namespaced as well.
Re: Typosquatting programming language package managers
#60We've gotten flack from package developers submitting new packages to Package Control [0] because all additions to the default channel are hand reviewed. Part of this process is to prevent accidentally close package names, to try and encourage collaboration and to encourage developers to actually explain what their package does and how to use it. My hope is to be automating a large amount of the review in the next fe…
One step to mitigate things like this as well would be to have some sort of "crowd-sourcing" command in the package manager program... like "npm flag coffe-script" or something like that to alert repository maintainers of possible issues.
[1]: http://central.sonatype.org/pages/ossrh-guide.html [2]: http://central.sonatype.org/articles/2014/Feb/27/why-the-wai...