4 ms·

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 are

by raggi 9y ago

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.

raggi 9y ago
And while we're at it https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5814 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.
- thehardsphere 9y ago
  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.
thehardsphere 9y ago
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.

by raggi 9y ago

raggi 9y ago

And while we're at it https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5814 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.

thehardsphere 9y ago
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.

thehardsphere 9y ago

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.