Malicious crossenv package on npm

I'm unconvinced that 514 is crazy.

In fact, the only unusual thing I see there is that the author knows that number.

Back in then 1990's PHP was very popular. To use it, you had to compile it yourself, which involved compiling Apache 1.3 with modules. There were also various image libraries, font libraries etc. It wouldn't surprise me at all if the dependency tree of that included hundreds of libraries.

There's no secure list of "good people" and there's no secure list that provides a mapping of who should be signing each package. Especially for things maintained by multiple people, I wouldn't have (and shouldn't have to have) any idea of which particular people are the proper signers.

same as what happens with all the package that were uploaded before the hypothetical GPG support was added to npam an packages could be signed.

>Which means I'm forced to trust that there are no exploits in NPM's authentication system

with signatures you are forced to trust NPM's authentication system to make sure that nobody has stripped a signature of a published package or changed the signature of an existing package.

Alternatively, it's up to you to keep track of all previously used signing identities of all your dependencies and to manually check the whole dependency tree if any of the keys in the tree have expired and been replaced.

> but all it takes to be able to sign things is[…]

unless you have more than one machine. If you do, you have to sync your keys between machines and just putting ~/.gpg on Dropbox (which would be ok as the keys are encrypted) won't do because there are still two maintained forks of GPG out there that work differently and require different config settings.

> And answering the interactive prompts

of which depending on GPG version some give bad advice with regards to key compatibility and strength and none of these prompts will help you deal with an expired key in the future (and yet, these prompts recommend you create one that expires after only a year).

Just stating `gpg --gnerate-key` as the complete solution will put people in position where in case of an emergency release they won't be able to publish that release because of previous administrative failure. That's a risky proposition.

And finally, the same malware that steals your 2FA token can also steal your ~/.gnupg and the passphrase once you enter it.

What I'm getting at is that gpg is actually significantly harder to use and maintain for users, requires significant updates to npm on both the server and client end, will cause false positives due to key changes and doesn't provide much more security than enforced 2FA authentication for publishing packages which would just require a small server-side change.

I get that you personally are totally willing to deal with a the maintainer's key of a dependency of a dependency of a dependency of yours having expired and thus being replaced with a new key and I also totally get that you yourself are willing to manually check the signatures of the whole dependency tree for changes (you're not willing to trust NPM itself as a public key repository, I get that, so you'll have to manually keep all previously used public keys around), but don't expect this same due-diligence from everybody else.

Once you trust NPM.com to manage identities (which is the only way to halfway conveniently deal with key rotation), everything hinges on NPM's authentication system again and at that point we're back to square one.

https://www.npmjs.com/package/check-typosquatters

(It's the first time I've published anything to npm so let me know if I have done anything wrong...)

It uses the list of package names from the all-the-package-names package and returns the 10 packages with the most similar names to the supplied parameter (using Levenshtein distance)

It also displays their rank based on dependent packages to give an idea of how they compare in usage.

I'm sure there are improvements that could be made - PRs welcome on the github repository.

NPM is such a massive package repository, it's sort of a testament to the community that these sorts of things don't happen more often.