Secure NPM

[wilk]

No description provided.

[wilk]

I tried to link it to the rfc's community forum but I can't do that because I got the following error: "Sorry you cannot post a link to that host."
May I consider this RFC opened?

[devsnek]

how does this fix the situation when malicious code runs on a user's computer, like with the most recent worm? in most cases people don't lock down their git push any more than they lock down their npm publish...

not to say that increased visibility is bad but I think this dodges the actual problem. some form of 2fa on every publish might be a better solution, although I'm sure that isn't a complete solution either.

[wilk]

@devsnek That's right, this is not THE solution, this is A solution, kinda improvement.
Preventing malicious code is a complex topic but this solution improves visibility and implement a sort of double-check by the NPM's server before a new package is being published.

[naugtur]

Would that be mandatory for each publish after it gets introduced? Sounds like a lot of work for the kinds of people with 100 published packages.

Would it be possible to have automation applicable to ~80% of cases?

[mjp0]

In my opinion this needs to be merged asap and should be mandatory in any future package updates. It makes no sense that we sacrifice even a small part of the security of all possible end users for the small inconvenience of adding a verification step in the build process that can and should be automated anyway.

[wilk]

Another relevant issue for this topic: dominictarr/event-stream#116

[superlbr]

why not maintain a blacklist in github

[kurtextrem]

@superlbr I don't think that would be the right solution, because you have to find compromised packages first in order to add them to a list. When that is the case, it is too late already (most likely).

[dead-claudia]

@wilk Attacking this is simple: direct npm to a Git branch that conveniently confirms its "integrity", then once you confirm it's published successfully, delete the commit and branch to cover your tracks.

[superlbr]

@kurtextrem there should be whitelist also, who is able to granted to maintain such an important repository，like grades in credit card

[zkat]

Hey, thanks for submitting this!

I believe this is a very roundabout way of achieving the sort of thing you'd get when using package signing, and the preferred solution here would be for us to get around to actually implementing and releasing package signing support in the CLI.

There are two significant problems with this proposal that I think are blockers to it moving forward:

1. It assumes git repositories will be existent and available reliably.
2. A large % of packages out there use files to selectively publish, and/or they use some sort of transpilation or bundling process, which will make shasums simply not match, or often not match.

As far as the quoted attacks, and other attacks go, this would either not solve it, or there's other, better solutions for the same attack, such as two-factor authentication and package signing.

We've decided we're going to continue to proceed in that direction, and so we'll be closing this PR. Thank you so much again for taking the time to write this and submit it, and thanks a bunch for everyone involved in the conversation. Keep an eye out for package signing! It's on our roadmap, as are other security features coming in 2019. Making sure the registry is safe to use is a very high priority for us, as is making sure that security doesn't compromise the quality of user experience our userbase has come to expect from npm.