I'm confused.. is it 17 computers or 17000 computers? inconsistent use of decimals in this article.
17,000. The author is from a country that uses . to delimit thousands.
Typosquatting programming language package managers
31–40 of 148 posts
Re: Typosquatting programming language package managers
#32Did 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…
Numerous developers and/or building multiple servers behind a single IP address aka NAT. It's pretty common.
Re: Typosquatting programming language package managers
#33Part of the problem is the many packages that require sudo permissions to install - IMHO that should be an exceptional case, but it isn't.
Re: Typosquatting programming language package managers
#34Did 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…
The person who ran the line,
sudo pip install lumpy (instead of numpy)
Ran it again because it 'didn't work'
Re: Typosquatting programming language package managers
#35So last week my client discovered there's a gem named bunlder... sigh
There is a gem called bundle which doesn't do anything but preventing a typosquat https://rubygems.org/gems/bundle Total downloads 1,800,600 Source (empty) at https://github.com/will/bundle and interesting README. https://rubygems.org/gems/bundler Total downloads 92,116,090 It's almost the 2%.
I think the authors here missed an opportunity for even more effective squatting like that: cases where the name you import, name you type at the command line, or name you commonly call the package by is different from the name in the repository.
In Python, "pytables" (should be "tables") and "skimage" (should be "scikit-image") come to mind.
Re: Typosquatting programming language package managers
#36Reminds me of the quote, 'there are only two hard things in computer science: naming things, cache invalidation and off-by-one errors.' I think that this clearly falls under the heading 'naming issue.' People know what they want, but do not enter it properly. I can't think of a 100% off-hand, which isn't surprising, because it's a hard problem. pmontra's suggestion to use typo blacklisting ain't a bad idea. Maybe som…
Banks have a similar problem when people write cheques or set up standing orders. You have to put a name and the account number. I wonder if you could do something similar here - enter the name of the package and a code of some sort. I haven't thought this through in a lot of detail.
Banks generally solve the issue with simple classic checksumming methods that guarantee that any number with a typo or swapped neighbouring characters will always result in an invalid number.
That doesn't work with arbitrary names because they are, well, arbitrary.
Re: Typosquatting programming language package managers
#37I'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
#38When you think about it, how different is the destructive potential of an npm/pip install from curl | bash that (some) people tend to froth at the mouth about? It's pretty mind blowing how big of a blindspot package installers are. I guess running everything inside a e.g. Docker container/VM would be a partial interim solution for the paranoid?
> When you think about it, how different is the destructive potential of an npm/pip install from curl | bash that (some) people tend to froth at the mouth about? It's a bit better - there is only one possible source of compromise rather than everyone on the network path. Given that npm/pip likely keep archives of all packages uploaded, it would be much harder (perhaps impossible) to attack someone secretly this way,…
Signing is definitely part of the answer but there's still the question of trust.
A signed package doesn't really tell you that much. In the best case scenario it tells you the package you're installing in fact came from developer X and contains code Y (which you kinda already know since you have the source code). This works as long as you know and trust developer X, or did your due diligence reading through the code (which you can already do today).
I can't think of an end solution that wouldn't have to rely on network effects and social proof, which strikes me as rather fragile. Maybe formal verification and AI can help, but that's a long way off (?)
Re: Typosquatting programming language package managers
#39Wow, this a very good study and explanation of what typo squatting is, and I really liked how he proved it's effectiveness. I wonder what kind of steps we can take to prevent this risk.
I think we will have to rely on crypto hash in some form. Similar to download checksum. It won't be convenient, but it will be safe(r).
That doesn't really save you from typos
Re: Typosquatting programming language package managers
#40And 'npmjs.org' is misspelled as 'npmsjs.org' in the introduction. Nice.