19 ms·

Java/Maven.

raggi 9y ago
So you use https://github.com/whispersystems/gradle-witness https://github.com/whispersystems/gradle-witness, and you manually verify everything you whitelist right? And you never typo, right?
- orf 9y ago
  I doubt he does, but i also doubt that installing a framework via maven brings in 1,000 implicit dependencies from 1,000 untrusted authors, unlike in JS land. Edit: react, webpack, babel, babel-preset-env bring in 1,257 dependencies. Try vetting all those by hand.
  - thehardsphere 9y ago
    I think my (primarily Java) project at work brings in about 50-100 external dependencies. That includes some ridiculously large frameworks, like Spring. Honestly, I don't know because I don't have dependency problems. You know how hard it would be for me to vet the dependency if I did have a dependency problem? "mvn dependency:tree > deps.txt." It would take half the day, but I could vet them all. I also have a Django project on the side. It has 8 dependencies. I have vetted all of them very carefully. It's smaller than the work project, but that's not the reason why it has fewer dependencies than a typical JS mess. It has fewer dependencies, because Pythonistas have a philosophy and cultural practices that produces quality software with lots of functionality included.
    - raggi 9y ago
      Npm being split means more metadata, not necessarily more code. You admit to not reading your code or inspecting your dep, and you assert that you have no problems - based on what? Your deps.txt is barely different than a lock file here. Reading the code from dependencies is not really hard anywhere here.
      - thehardsphere 9y ago
        > you assert that you have no problems - based on what? The software works as intended and I know that my dependencies have not changed without me explictly changing them. > Your deps.txt is barely different than a lock file here. That command produces a tree of all dependencies and their dependencies. I don't know what that has to do with a lock file.
- thehardsphere 9y ago
  0. What I do is irrelevant to whether or not the other people in the community have solved that problem. Which they have. 1. That's a Gradle plugin. I do not use Gradle. I use Maven. 2. I don't need to "manually verify everything I whitelist" (which is not exactly how Maven works but w/e) because everything in Central is cryptographically signed and can't be replaced simply because someone deleted all of their projects in a fit of pique, and some other person swooped in and used the exact same name. 3. I don't have to worry about typos, because I can't add a dependency to my project without editing the project's POM, so fat fingering on the command line cannot add random packages to the project. Plus, Maven artifacts are namespaced, so I would have to be pretty drunk to make so many typos that a different, existing package downloaded.
  - 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.

Java/Maven.

So you use https://github.com/whispersystems/gradle-witness https://github.com/whispersystems/gradle-witness, and you manually verify everything you whitelist right? And you never typo, right?

orf 9y ago
I doubt he does, but i also doubt that installing a framework via maven brings in 1,000 implicit dependencies from 1,000 untrusted authors, unlike in JS land. Edit: react, webpack, babel, babel-preset-env bring in 1,257 dependencies. Try vetting all those by hand.
- thehardsphere 9y ago
  I think my (primarily Java) project at work brings in about 50-100 external dependencies. That includes some ridiculously large frameworks, like Spring. Honestly, I don't know because I don't have dependency problems. You know how hard it would be for me to vet the dependency if I did have a dependency problem? "mvn dependency:tree > deps.txt." It would take half the day, but I could vet them all. I also have a Django project on the side. It has 8 dependencies. I have vetted all of them very carefully. It's smaller than the work project, but that's not the reason why it has fewer dependencies than a typical JS mess. It has fewer dependencies, because Pythonistas have a philosophy and cultural practices that produces quality software with lots of functionality included.
  - raggi 9y ago
    Npm being split means more metadata, not necessarily more code. You admit to not reading your code or inspecting your dep, and you assert that you have no problems - based on what? Your deps.txt is barely different than a lock file here. Reading the code from dependencies is not really hard anywhere here.
    - thehardsphere 9y ago
      > you assert that you have no problems - based on what? The software works as intended and I know that my dependencies have not changed without me explictly changing them. > Your deps.txt is barely different than a lock file here. That command produces a tree of all dependencies and their dependencies. I don't know what that has to do with a lock file.
thehardsphere 9y ago
0. What I do is irrelevant to whether or not the other people in the community have solved that problem. Which they have. 1. That's a Gradle plugin. I do not use Gradle. I use Maven. 2. I don't need to "manually verify everything I whitelist" (which is not exactly how Maven works but w/e) because everything in Central is cryptographically signed and can't be replaced simply because someone deleted all of their projects in a fit of pique, and some other person swooped in and used the exact same name. 3. I don't have to worry about typos, because I can't add a dependency to my project without editing the project's POM, so fat fingering on the command line cannot add random packages to the project. Plus, Maven artifacts are namespaced, so I would have to be pretty drunk to make so many typos that a different, existing package downloaded.
- 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.