16 ms·

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

by slackingoff2017 9y ago

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 to my account and tries to modify my package without my private key it will not be accepted into the repo. And actually, I'm pretty sure maven signs not just the code but also the documentation and everything else within your package. Light-years ahead of NPM, even after their publicized issues.

detaro 9y ago
How does "You need my private key to sign the cross-env package" stop someone from creating a "crossenv" package? What does the specific workflow look like that makes sure I don't add the wrong thing to my project?
- chii 9y ago
  It doesn't. They's not the problem being solved by signing. In all likelihood, if an end user got socially engineered to download the wrong package, there's very little to be done. Perhaps the install process can do a search and display similarly named packages, and the users could be more alert to irregularly named ones?
  - KirinDave 9y ago
    What's to be done is remove the package and try and dox the perpetrator to kingdom come, in hopes that law enforcement and social reputation can make an example of of them.
    - _jal 9y ago
      That method does not scale. Additionally, it assumes that members of law enforcement are not publishing malware.
      - KirinDave 9y ago
        I assure you my malice scales infinitely.
    - jsjohnst 9y ago
      You should've stopped at the first "and". Advocating for vigilante justice helps solve no problems.
      - KirinDave 9y ago
        I think you're reading a lot more into my comment than I wrote. It's not "vigilante justice" to ban known scammers and circulate blacklists of them. It's how our community functions.
        jsjohnst 9y ago
        > dox the perpetrator to kingdom come, in hopes that law enforcement and social reputation can make an example of of them. Is a hell of a lot closer to "vigilante justice" than the version you just said. Had you made the sane posting first (or not pretended you did the second time) I wouldn't have said anything and just upvoted in agreement.
        KirinDave 9y ago
        Which part of the statement implied "vilgilate justice." The part with the law enforcement or the "social reputation" part that is exactly the words game theory uses when discussing bad actor in a problem. Just so I can modify my words to avoid future misunderstanding.
        jsjohnst 9y ago
        > dox the perpetrator to kingdom come I can't believe it wasn't obvious, but that's the part which implies vigilante justice. From Wikipedia[0]: A vigilante is a civilian or organization acting in a law enforcement capacity (or in the pursuit of self-perceived justice) without legal authority. Doxing has a very specific meaning and it directly implies taking matters into your own hands, aka vigilante. [0] https://en.m.wikipedia.org/wiki/Vigilante https://en.m.wikipedia.org/wiki/Vigilante
        9y ago
- danjoc 9y ago
  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 about him. I find his twitter @kentcdodds for instance. He may even have a page published @doddsfamily.com to verify his key. If the key has been around for a while, that's probably sufficient for me. If he doesn't have such a page, I send him a polite message, "Hi Kent. I'm evaluating your software for use in my project. Can I get you to verify your key please?" and Kent is a professional, so he agrees. I send kent@doddsfamily.com an encrypted message and he sends me an encrypted reply. Done. I'm satisfied that he controls the key. At this point... oh, wow. That's not my key! Did you say crossenv? My package is cross-env! Alert the Node authorities! There's a malicious package pretending to be mine! Is that 100% infallible? No, but here's the great thing. Even though my verification system may not be bulletproof, others with resources like DoD or FBI are out there verifying keys. They'll go see Mr Dodds, in person, if they have to. In this way, key verification is a bit like herd immunity. And the older the key is, the more trustworthy it probably is. People who are here arguing against this system have a few things in common. They don't propose a better system, because they don't have one. They're also a bit like anti-vaxers. They irrationally refuse to participate in such a system to everyone elses' detriment. They're a bit like congress as well. They can't just look at a working system like single payer, and copy it. They refuse to accept that this is the best available option, so they fold their arms and actively fight any attempt to implement it, as is the case on that github 4016 issue. So now that I've maybe offended everyone, strike me down with down votes. That's the basics of how I would go about it though.
  - KirinDave 9y ago
    Hashes already exist. The problem is not a lack of integrity verification. We have that. The problem is not a lack of identity verification, we haven't really shown that NPM is lacking for that. The problem is one of addressing. People want to get packages by a utf8 and natural language string, followed by a version boundary check. If people referred to packages by their proper hash (as one does when referencing values from IPFS), then we wouldn't have this problem. If people had a public key and added a key fingerprint that would also work, but would not provide any additional verification to the code (1). But people don't want to do this. They want to address packages by relatively simple and memorable tuples. That is the problem. > They're also a bit like anti-vaxers. They irrationally refuse to participate in such a system to everyone elses' detriment. They're a bit like congress as well. They can't just look at a working system like single payer, and copy it. You aren't even in Keybase. Have you personally participated in any keysigning parties? Can I find your public key details here? I can answer yes to all 3 above questions. > So now that I've maybe offended everyone, strike me down with down votes. That's the basics of how I would go about it though. You haven't actually offended everyone. What you haven't done is say anything that anyone else doesn't know already. We all know how signature verification worksheet and we all have seen it's problems in real world implementations. Please reconsider paragraphs like this. (1) :: The thing this would do is make it arguably more secure contacting the author or maintainers of the code, although given GPG's failure to achive widespread adoption or integration in popular tooling, it seems unlikely it'll see much utility.
- vacri 9y ago
  GPG-signing doesn't prove maliciousness, it just proves authenticity; that it was written by a particular person. The web-of-trust is used to enforce social reputation - if a user is malicious, their key is revoked. If a user signs up poor-quality other users, their key is revoked. Blacklists go stale and are also hard to get off if you've landed on one in error. Webs-of-trust are more work, but more robust.
KirinDave 9y ago
Maybe I just don't understand, so could you explain to me how gpg signatures actually fix this problem? Would they fix this problem for npm? I'm asking about the specific attack detailed in the tweet.
skywhopper 9y ago
I'm guessing maven feels safer because its packages must be compiled against a specific interface and few if any execute any code during setup. Maven is rarely if ever used to install interactive tools like npm very often is. Maven is not a reasonable analog here.
- jhundal 9y ago
  Somewhat agreed, maven is a build tool and packages it downloads do not execute code through maven. This does not preclude malicious typosquatting packages making it into applications built using it, but does provide some option for reducing the attack surface. In practice I think most developers would be running their project on the same exact box as they use for building it, which nullifies the separation of build/runtime environment. The reason that we don't typically see egregious typosquatting in the Java ecosystem is that Sonatype has a manual check on the claimed namespace for the organization publishing a project (among other checks). npm, Inc. could do this, but they so far have chosen not to. Edit: Typos/clarity
- KirinDave 9y ago
  People keep saying this, but it's easy to imagine that the malicious code in a maven-included package only works when it detects it's being invoked in a unit test, which puts it in build time easily. It's true it doesn't immediately build on site, but it sure could run in the developer's machine.
hedora 9y ago
Does maven really reliably validate packages these days? I once did a mvn build on a southwest flight and got stuff like "Syntax error: <h1>Click here for free TV..." all over my console. This was ~4 years ago. If I remember right, maven "supported" package validation, but it was certainly not the de facto standard.
- cakeface 9y ago
  Great point. I think that Maven Central is great about checking incoming packages. But most maven clients are really bad. The default in maven client is usually to download via http. The default is usually to _not_ check the hash. There is not a great way to pin a library to a repository which, when coupled with the ease of third-party repositories slipping into your project, means that you can download things like your crypto oauth library from some random server on the web. Many of these issues can be mitigated by running your own repository that mirrors what you need. Most big corporate shops do this. I think that approach works for any package management system. I guess open source devs and hobbiests are screwed?
- danjoc 9y ago
  Yes https://github.com/s4u/pgpverify-maven-plugin https://github.com/s4u/pgpverify-maven-plugin There's also this, https://jeremylong.github.io/DependencyCheck/dependency-check-maven/configuration.html https://jeremylong.github.io/DependencyCheck/dependency-chec... Because you want to know when a dependency has a vulnerability, even when the developers are legit.
- lmm 9y ago
  The repository enforces it. The client doesn't check by default which is a poor default, but at least checking is possible for those who care.
veeti 9y ago
> 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 into the repo. This isn't true. Sonatype/Maven Central requires PGP signatures on all new artifacts, but there is no requirement to use the same key. It will happily accept a signature from _any_ key for new releases. [1] https://github.com/WhisperSystems/Signal-Android/blob/ae93038d6651b564f4957ecdcab7323346153bf2/build.gradle#L122 https://github.com/WhisperSystems/Signal-Android/blob/ae9303...
- ulldma 9y ago
  Yes, this is important: Maven Central/Sonatype only checks if the submitted artifacts are signed (regardless of the used key). 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 https://issues.apache.org/jira/browse/MNG-6026

detaro 9y ago

How does "You need my private key to sign the cross-env package" stop someone from creating a "crossenv" package? What does the specific workflow look like that makes sure I don't add the wrong thing to my project?

chii 9y ago
It doesn't. They's not the problem being solved by signing. In all likelihood, if an end user got socially engineered to download the wrong package, there's very little to be done. Perhaps the install process can do a search and display similarly named packages, and the users could be more alert to irregularly named ones?
- KirinDave 9y ago
  What's to be done is remove the package and try and dox the perpetrator to kingdom come, in hopes that law enforcement and social reputation can make an example of of them.
  - _jal 9y ago
    That method does not scale. Additionally, it assumes that members of law enforcement are not publishing malware.
    - KirinDave 9y ago
      I assure you my malice scales infinitely.
  - jsjohnst 9y ago
    You should've stopped at the first "and". Advocating for vigilante justice helps solve no problems.
    - KirinDave 9y ago
      I think you're reading a lot more into my comment than I wrote. It's not "vigilante justice" to ban known scammers and circulate blacklists of them. It's how our community functions.
      - jsjohnst 9y ago
        > dox the perpetrator to kingdom come, in hopes that law enforcement and social reputation can make an example of of them. Is a hell of a lot closer to "vigilante justice" than the version you just said. Had you made the sane posting first (or not pretended you did the second time) I wouldn't have said anything and just upvoted in agreement.
        KirinDave 9y ago
        Which part of the statement implied "vilgilate justice." The part with the law enforcement or the "social reputation" part that is exactly the words game theory uses when discussing bad actor in a problem. Just so I can modify my words to avoid future misunderstanding.
        jsjohnst 9y ago
        > dox the perpetrator to kingdom come I can't believe it wasn't obvious, but that's the part which implies vigilante justice. From Wikipedia[0]: A vigilante is a civilian or organization acting in a law enforcement capacity (or in the pursuit of self-perceived justice) without legal authority. Doxing has a very specific meaning and it directly implies taking matters into your own hands, aka vigilante. [0] https://en.m.wikipedia.org/wiki/Vigilante https://en.m.wikipedia.org/wiki/Vigilante
        9y ago
danjoc 9y ago
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 about him. I find his twitter @kentcdodds for instance. He may even have a page published @doddsfamily.com to verify his key. If the key has been around for a while, that's probably sufficient for me. If he doesn't have such a page, I send him a polite message, "Hi Kent. I'm evaluating your software for use in my project. Can I get you to verify your key please?" and Kent is a professional, so he agrees. I send kent@doddsfamily.com an encrypted message and he sends me an encrypted reply. Done. I'm satisfied that he controls the key. At this point... oh, wow. That's not my key! Did you say crossenv? My package is cross-env! Alert the Node authorities! There's a malicious package pretending to be mine! Is that 100% infallible? No, but here's the great thing. Even though my verification system may not be bulletproof, others with resources like DoD or FBI are out there verifying keys. They'll go see Mr Dodds, in person, if they have to. In this way, key verification is a bit like herd immunity. And the older the key is, the more trustworthy it probably is. People who are here arguing against this system have a few things in common. They don't propose a better system, because they don't have one. They're also a bit like anti-vaxers. They irrationally refuse to participate in such a system to everyone elses' detriment. They're a bit like congress as well. They can't just look at a working system like single payer, and copy it. They refuse to accept that this is the best available option, so they fold their arms and actively fight any attempt to implement it, as is the case on that github 4016 issue. So now that I've maybe offended everyone, strike me down with down votes. That's the basics of how I would go about it though.
- KirinDave 9y ago
  Hashes already exist. The problem is not a lack of integrity verification. We have that. The problem is not a lack of identity verification, we haven't really shown that NPM is lacking for that. The problem is one of addressing. People want to get packages by a utf8 and natural language string, followed by a version boundary check. If people referred to packages by their proper hash (as one does when referencing values from IPFS), then we wouldn't have this problem. If people had a public key and added a key fingerprint that would also work, but would not provide any additional verification to the code (1). But people don't want to do this. They want to address packages by relatively simple and memorable tuples. That is the problem. > They're also a bit like anti-vaxers. They irrationally refuse to participate in such a system to everyone elses' detriment. They're a bit like congress as well. They can't just look at a working system like single payer, and copy it. You aren't even in Keybase. Have you personally participated in any keysigning parties? Can I find your public key details here? I can answer yes to all 3 above questions. > So now that I've maybe offended everyone, strike me down with down votes. That's the basics of how I would go about it though. You haven't actually offended everyone. What you haven't done is say anything that anyone else doesn't know already. We all know how signature verification worksheet and we all have seen it's problems in real world implementations. Please reconsider paragraphs like this. (1) :: The thing this would do is make it arguably more secure contacting the author or maintainers of the code, although given GPG's failure to achive widespread adoption or integration in popular tooling, it seems unlikely it'll see much utility.
vacri 9y ago
GPG-signing doesn't prove maliciousness, it just proves authenticity; that it was written by a particular person. The web-of-trust is used to enforce social reputation - if a user is malicious, their key is revoked. If a user signs up poor-quality other users, their key is revoked. Blacklists go stale and are also hard to get off if you've landed on one in error. Webs-of-trust are more work, but more robust.

KirinDave 9y ago

Maybe I just don't understand, so could you explain to me how gpg signatures actually fix this problem? Would they fix this problem for npm? I'm asking about the specific attack detailed in the tweet.

skywhopper 9y ago

I'm guessing maven feels safer because its packages must be compiled against a specific interface and few if any execute any code during setup. Maven is rarely if ever used to install interactive tools like npm very often is. Maven is not a reasonable analog here.

jhundal 9y ago
Somewhat agreed, maven is a build tool and packages it downloads do not execute code through maven. This does not preclude malicious typosquatting packages making it into applications built using it, but does provide some option for reducing the attack surface. In practice I think most developers would be running their project on the same exact box as they use for building it, which nullifies the separation of build/runtime environment. The reason that we don't typically see egregious typosquatting in the Java ecosystem is that Sonatype has a manual check on the claimed namespace for the organization publishing a project (among other checks). npm, Inc. could do this, but they so far have chosen not to. Edit: Typos/clarity
KirinDave 9y ago
People keep saying this, but it's easy to imagine that the malicious code in a maven-included package only works when it detects it's being invoked in a unit test, which puts it in build time easily. It's true it doesn't immediately build on site, but it sure could run in the developer's machine.

hedora 9y ago

Does maven really reliably validate packages these days? I once did a mvn build on a southwest flight and got stuff like "Syntax error: <h1>Click here for free TV..." all over my console. This was ~4 years ago. If I remember right, maven "supported" package validation, but it was certainly not the de facto standard.

cakeface 9y ago
Great point. I think that Maven Central is great about checking incoming packages. But most maven clients are really bad. The default in maven client is usually to download via http. The default is usually to _not_ check the hash. There is not a great way to pin a library to a repository which, when coupled with the ease of third-party repositories slipping into your project, means that you can download things like your crypto oauth library from some random server on the web. Many of these issues can be mitigated by running your own repository that mirrors what you need. Most big corporate shops do this. I think that approach works for any package management system. I guess open source devs and hobbiests are screwed?
danjoc 9y ago
Yes https://github.com/s4u/pgpverify-maven-plugin https://github.com/s4u/pgpverify-maven-plugin There's also this, https://jeremylong.github.io/DependencyCheck/dependency-check-maven/configuration.html https://jeremylong.github.io/DependencyCheck/dependency-chec... Because you want to know when a dependency has a vulnerability, even when the developers are legit.
lmm 9y ago
The repository enforces it. The client doesn't check by default which is a poor default, but at least checking is possible for those who care.

veeti 9y ago

> 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 into the repo. This isn't true. Sonatype/Maven Central requires PGP signatures on all new artifacts, but there is no requirement to use the same key. It will happily accept a signature from _any_ key for new releases. [1] https://github.com/WhisperSystems/Signal-Android/blob/ae93038d6651b564f4957ecdcab7323346153bf2/build.gradle#L122 https://github.com/WhisperSystems/Signal-Android/blob/ae9303...

ulldma 9y ago
Yes, this is important: Maven Central/Sonatype only checks if the submitted artifacts are signed (regardless of the used key). 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 https://issues.apache.org/jira/browse/MNG-6026