Live data from Hacker News

Typosquatting programming language package managers

incolumitas.com

121–130 of 148 posts

Re: Typosquatting programming language package managers

#121
post #106
post #88

Earlier quoted context omitted.

Well, you could also solve it by saying that the post slash names are unique. ie. There can't exist zardeh/serde if erickt/serde already exists. Then the author-name works as a logical checksum, and you aren't any worse off than you were with a global namespace.

The purpose of a namespace is to make it possible to disambiguate two otherwise identical identifiers. If you force package names to be unique across all namespaces, then you don't have namespaces at all, you just have a single global namespace where you're forced to prepend an author name to the package name.

I know, I wasn't suggesting this as a namespacing solution, but instead a typo-prevention one.

Re: Typosquatting programming language package managers

#122
post #101

Earlier quoted context omitted.

Why not? Central repositories could require that all names are within a certain Levenshtein distance of one another. This could get mildly annoying every once in a while when there are legitimate non-clashing names. A better metric/typo recognition technique is probably possible. Or else some manual process for requesting exceptions (maybe with a tiny fee to help fund the overall project) would also address this prob…

"Sorry, the otherwise 100% valid and reasonable name you've selected for your project is invalid because an algorithm has determined it is arbitrarily too close to this other unrelated project. Try again." Who would use that?

"The project title has been flagged due to similarity with an existing name. Your submission has been sent for moderator review".

Package managers have humans to deal with edge cases (removing malicious packages, investigating package errors, etc.) and this is no different. It wouldn't significantly increase their burden because only a small fraction of package names should require human validation.

Re: Typosquatting programming language package managers

#123
post #15

Earlier quoted context omitted.

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.

Or just refer to packages by 2 names. Maintainer/PackageName It solves so many problems, this included.

That gets into issues with needing to either support multiple individual maintainers for a single package, or require any multi-maintainer package to create an organization they'll all work under, and use the org name. And since the org name is likely to be the name of the package, you're back at square 1.

For example, on the Python Package Index five people have authorization to publish a new Django release. Creating a "Django" org namespace wouldn't help, since someone could typo the org name and hit a squatted malicious version (and that's almost certainly what it would end up being; our github org is named "django").

Re: Typosquatting programming language package managers

#124

Part of the problem is the many packages that require sudo permissions to install - IMHO that should be an exceptional case, but it isn't.

Packages often require sudo in order to install to the global interpreter - it's a security hazard otherwise. Imagine a Python package which overrides the sys module. If it didn't require sudo, anyone could install it and compromise Python for everyone else (or, for instance, compromise setuid programs).

The two solutions here are user-local packages (pip --user, for example) and virtual environments.

Re: Typosquatting programming language package managers

#125
post #97
post #86

Earlier quoted context omitted.

I feel like "pick the more popular package" is a good enough solution in this case.

Cool. Attacker-defender race is on ! As attacker, my next strategy is create a bunch of agents ( Your move, defender ;) But seriously, my point has less to do with the particular tactics of the adversaries and more to do with how the proposed strategy of automatically detecting potential typos invites gaming.

Perfect, if each of those 10K hosts downloads the library 100 times you can now typo-attack the zope.event (working in python) library, which gets ~100 downloads per day, many of which are automated and so invulnerable to your attack. Your attack vector gets you, we'll say 1 new hit every 2 days at most, and likely only one a week or so (according to some math, on `requst` vs. requests)

Re: Typosquatting programming language package managers

#126

Earlier quoted context omitted.

Yeah I wouldn't want to find myself in court hearing >17000 computers were forced to execute [unauthorized] arbitrary code Certainly a crime in the US, not sure about Germany. Nice execution though!

I'm not so sure - were they forced? Could you take the maintainer of `requests` to court too? If someone types `pip install reqeusts` and gets something they maybe didn't expect, did you really force them?

Are you asking if the maintainer of 'requests' decides to spy on computers and phone home information?

What packages do this?

Re: Typosquatting programming language package managers

#127
post #5

I'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?

That's a massive burden on the poor person who has to ok the package - especially at NPM's scale, for example.

We believe npm's scale is a direct result of having the lowest ceremony to publish a package. Turning the dial in the direction we did has pros and cons.

Re: Typosquatting programming language package managers

#128

with npm there should be at least an option which prompts for Y/N/A when package has preinstall hook. but even this just tries to put the problem under carpet. you could still for example have requests package which just installs request package, works as expected, just sends request/response to your own server from time to time. ie. when there's http basic auth used only.

It is possible to disable install hooks at install time by running npm install with --ignore-scripts.

You can also make this the default, with npm config set ignore-scripts true (and then --ignore-scripts false at install time if you wish to run them).

Re: Typosquatting programming language package managers

#129
post #88

Earlier quoted context omitted.

Well, you could also solve it by saying that the post slash names are unique. ie. There can't exist zardeh/serde if erickt/serde already exists. Then the author-name works as a logical checksum, and you aren't any worse off than you were with a global namespace.

That reduces the likelihood of success (erick-t/srede requires 2 typos) but doesn't eliminate the possibility.

True, but two simultaneous and specific typos is much, much less likely than a single one.

Re: Typosquatting programming language package managers

#130

Earlier quoted context omitted.

I'm not so sure - were they forced? Could you take the maintainer of `requests` to court too? If someone types `pip install reqeusts` and gets something they maybe didn't expect, did you really force them?

Are you asking if the maintainer of 'requests' decides to spy on computers and phone home information? What packages do this?

Not a laywer, I'm just picking nits. It seems to me when you pip install a package, you are saying "download and run its setup.py file". What if requests did something you didn't like, something simple like write a new directory or change the name of a certain file. Could you sue over that? Where is the distinction?
Post reply on HN