Malicious crossenv package on npm

Re:Malicious crossenv package on npm by raggi on Thursday August 03, 2017 @03:37AM (#14917675)

2. If you don't whitelist your deps, then your dep chain can change with any update. Signing keys prove only that the publisher held the keys, not that they aren't malicious, or that the keys aren't stolen.

3. Fat fingering your pom is no different, this argument is as wasteful as 0 and 1 and you know it.

[ Parent | on HN ]

Re:Malicious crossenv package on npm by thehardsphere on Thursday August 03, 2017 @09:35AM (#14919393)

I didn't say that "I don't whitelist my deps." I said I don't need to manually verify every tiny thing that I whitelist.

If you actually knew what you what you were talking about, you would know that you can't specify a dependency in a Maven POM without specifying a version, so everything is effectively version pinned and doesn't magically change unless you do it explictly. And you can't change an artifact after it has been released; you have to issue a new release with different coordinates. These are features of Maven that npm is missing that would make it vastly more secure than it is now.

And fat fingering a pom is different, because it requires many more mistakes to download some other software package than the one intended. That's what this discussion is about right? That it's absurdly easy to download the wrong package on npm but not other package managers, because npm is an insecure package manager.

[ Parent | on HN ]

Re:Malicious crossenv package on npm by raggi on Thursday August 03, 2017 @04:04AM (#14917805)

And while we're at it

https://issues.apache.org/jira/plugins/servlet/mobile#issue/...

Also, if you read the docs you'll notice that the deploy plugins encourage users to put their central passwords in an xml file in the plain AND their pgp key passphrase in another, in the plain. No joke. Read the docs.

[ Parent | on HN ]

Re:Malicious crossenv package on npm by thehardsphere on Thursday August 03, 2017 @09:50AM (#14919525)

An injection attack on a download is not one of the problems we're actually talking about here. That's a problem that affects any package manager.

And it's patently false to say that the deploy plugin documentation encourages you to include that information. They very clearly preface that with "if your repository is secured" and use the explicit example of an internal repository within a corporate context. People smart enough to read that documentation in detail should also be smart enough to determine when it is and isn't a good idea to do that.

[ Parent | on HN ]