Earlier quoted context omitted.
Not really different from any other typo-squatting (e.g. domains).
Except that in this case you're installing software on your computer, not just visiting a webpage.
Malicious crossenv package on npm
171–180 of 237 posts
Re: Malicious crossenv package on npm
#172Friendly reminder, every time this happens... https://github.com/npm/npm/pull/4016 "However, this is just a piece of an overall solution, and it brings with it a lot of the baggage that comes along whenever GnuPG or PGP get involved. Without a web of trust (sigh), a PKI (ugh), or some other mechanism to tie identities to trust metrics, this is essentially a complicated, very expensive, and fragile version of the shas…
Who?
Re: Malicious crossenv package on npm
#173Earlier quoted context omitted.
Maven prevents this as well. To add a package to the global repository you need to show ownership of your namespace by posting your key, your website, your email, or most commonly these days your GitHub repo with identifying information. They do check to make sure you're allowed to use each package identifier. All package submissions are hand-curated, which should catch typosquatters. There's a clearly laid out patte…
Well npm requires you to login through their CLI in order to publish packages... The only difference is that you use a password instead of a key. No difference.
Yes, there is a difference, released must be digitally signed on maven. They are not on NPM, so a hacker can hijack your packages just by obtaining your npm credentials.
That's crypto 101 and you can't tell the difference?
Re: Malicious crossenv package on npm
#174Re: Malicious crossenv package on npm
#175Earlier quoted context omitted.
I can explain how it can be done. Let's say you need a new dependency. You can't just add it to the project. Management would kill you. There's a lot of checks you have to make. Like licenses and signatures. In this case, you're concerned about signatures. I'll stick to that. If I believe I need crossenv, I see it advertises kent@doddsfamily.com as the author. I look up Kent Dodds. I find various bits of information…
One of the central problems of trust is that simple solutions don't scale well. Back in the day, one acquired a .com address by sending someone an email, because everyone knew everyone. cross-env has had 1.3 million downloads in the last month. How many of those "hey, I am evaluating your library" emails can Dodds field? Most node projects have hundreds of dependencies, if you include transitive dependencies. How man…
But yeah, everyone contacing an author directly doesn't scale at all.
Re: Malicious crossenv package on npm
#176Earlier quoted context omitted.
Maven does not have this problem. That package was just something you googled that hasn't been updated in two years because maven has required signed packages forever. My packages are all cryptographically signed with my private key. Maven doesn't just offer code signing, it's mandatory to deploy projects to the central repo. The automated package verifier will reject you if you don't have it. If someone gains access…
> That package was just something you googled that hasn't been updated in two years because maven has required signed packages forever. That something hasn't been updated in two years because it's feature complete and does what it's supposed to: verifies the integrity of dependencies for Signal [1]. > If someone gains access to my account and tries to modify my package without my private key it will not be accepted i…
The work is shifted to client, but there's currently no standardized way on how to verify dependencies and plugins.
There's an issue in the Maven bug tracker with the idea to extend the POM to allow trust information: https://issues.apache.org/jira/browse/MNG-6026
Re: Malicious crossenv package on npm
#177We also don't want shards to become yet another system package manager, used for installing executables to your PATH. Shards should never be run as root, unlike npm and pip.
Re: Malicious crossenv package on npm
#178You will, of course break production for a few people who just didn't listen.
Alternatively, instead of edit distance, allow users to report problematic packages and do a similar thing. Do not provide a explicit award to users who report, so nobody would create fake malware just to report it.
In both cases, either implicitly or explicitly you are using the wisdom of the crowd to figure out the bad packages.
Re: Malicious crossenv package on npm
#179Earlier quoted context omitted.
Maven prevents this as well. To add a package to the global repository you need to show ownership of your namespace by posting your key, your website, your email, or most commonly these days your GitHub repo with identifying information. They do check to make sure you're allowed to use each package identifier. All package submissions are hand-curated, which should catch typosquatters. There's a clearly laid out patte…
Well npm requires you to login through their CLI in order to publish packages... The only difference is that you use a password instead of a key. No difference.
Npm is a public internet login with a password of your choosing, probably the most insecure form of authentication there is bar doing nothing. I could be brute forcing your login credentials right now and you wouldn't even know.
Also, users are safe even if maven itself is compromised because attackers still can't validate my private key. I don't think you could say the same about npm...