5 ms·

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 s

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.

hedora 9y ago
I guess you are aguing that you can't find 10-ish core npm maintainers that can be bothered to sign keys for well-known developers and bootstrap a web of trust that would then provide crypto attestation and perform basic gatekeeping on new package submissions. It's not like you'd have to write a bunch of software. Also, other mission-critical open source repos have been doing this for at least a decade, so you don't even have to invent and validate a new set of processes for this. For me, this calls into question the reliability and quality of the whole npm infrastructure and the packages it hosts. Also, blaming users because npm (knowingly, through willful negligence) hosts malicious packages that typo squat on legitimate packages doesn't seem appropriate to me.
slackingoff2017 9y ago
Maven prevents this as well. To add a package to the global repository you need to show ownership of your namespace by posting your key, your website, your email, or most commonly these days your GitHub repo with identifying information. They do check to make sure you're allowed to use each package identifier. All package submissions are hand-curated, which should catch typosquatters. There's a clearly laid out pattern for what package space you're allowed to use based on website or company ownership. The system is highly automated but you have to wait to get your namespace approved. And it's not unrealistic to do this with npm, maven has somewhere over a million packages.
- jondubois 9y ago
  Well npm requires you to login through their CLI in order to publish packages... The only difference is that you use a password instead of a key. No difference.
  - camus2 9y ago
    > Well npm requires you to login through their CLI in order to publish packages... The only difference is that you use a password instead of a key. No difference. Yes, there is a difference, released must be digitally signed on maven. They are not on NPM, so a hacker can hijack your packages just by obtaining your npm credentials. That's crypto 101 and you can't tell the difference?
    - KirinDave 9y ago
      > so a hacker can hijack your packages just by obtaining your npm credentials. Couldn't they 'just' steal your GPG key as well? If someone can trivially steal a strong password from you, I'd worry about key material as well. > That's crypto 101 and you can't tell the difference? Please reconsider sentences like these.
      - sloppycee 9y ago
        The issue is of who to trust, the package maintainer or the package repository? It is comparatively trivial to steal a strong password when it is transmitted over the internet vs local key material. Nation states with bad certs (china has done this) can steal your password, npm can steal your password, npm can be hacked and leak passwords, npm can be subject to a NSL and forced to hand over passwords, etc, etc. There is a big difference between passwords and keys.
tomc1985 9y ago
Yeah I'm not really following how users desiring a natural-language tuple-looking thing prevents proper identity verification. Even without namespacing strong identity controls (signature verification and preventing unauthorized accounts from posting under a taken name, for example) can prevent most attacks short of typosquatting.
- stupidcar 9y ago
  Typosquatting is exactly what these malicious packages were doing. So you're agreeing that arguments re. identify verification is a useless distraction in this case?
- KirinDave 9y ago
  You seem to have a handle on every aspect of this situation except what the actual attack we're discussing was. It was typo squatting.
  - tomc1985 9y ago
    And you like to assume things. Name canonicalization gets you part of the way there. But unless you want to go full-on namespacing then you must realize you are fighting a pointless battle. You cannot reasonably expect to save users from themselves in every way.
    - KirinDave 9y ago
      Npm has namespacing.
lmm 9y ago
> 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). The hash naturally changes with every release. The key fingerprint doesn't. Updating your dependencies to new releases is much, much more frequent than adding a new dependency; people are willing to put more effort into the latter than the former. > You aren't even in Keybase. Have you personally participated in any keysigning parties? Can I find your public key details here? Keybase encourages poor practices and as such I avoid it. But I've been to keysigning parties and my key's details are published any number of places. (Since adding one more is all to the good, the fingerprint is 400A C7D2 E7A1 802A AE2C C459 B1E5 712A 6D03 3D61)
- KirinDave 9y ago
  I don't understand why you feel that the keybase question was directed at you. The decision to enter into this part of the discussion definitely hurt otherwise interesting post. It's true that a signature is based around a component with longer lifespan than a hash. However the management and trust of that component damages this argument severely. I am unaware of any web of trust in active use that could operate a npm scale existing today. Could you share one with me?
  - graphememes 9y ago
    Because it was a direct reply to the individual. If used as an example you should give context, otherwise your comments are directed towards who you reply to.
    - KirinDave 9y ago
      I didn't reply to lmm. I asked that question of danjoc. Is that not obvious from scrolling?

hedora 9y ago

I guess you are aguing that you can't find 10-ish core npm maintainers that can be bothered to sign keys for well-known developers and bootstrap a web of trust that would then provide crypto attestation and perform basic gatekeeping on new package submissions. It's not like you'd have to write a bunch of software. Also, other mission-critical open source repos have been doing this for at least a decade, so you don't even have to invent and validate a new set of processes for this. For me, this calls into question the reliability and quality of the whole npm infrastructure and the packages it hosts. Also, blaming users because npm (knowingly, through willful negligence) hosts malicious packages that typo squat on legitimate packages doesn't seem appropriate to me.

slackingoff2017 9y ago

Maven prevents this as well. To add a package to the global repository you need to show ownership of your namespace by posting your key, your website, your email, or most commonly these days your GitHub repo with identifying information. They do check to make sure you're allowed to use each package identifier. All package submissions are hand-curated, which should catch typosquatters. There's a clearly laid out pattern for what package space you're allowed to use based on website or company ownership. The system is highly automated but you have to wait to get your namespace approved. And it's not unrealistic to do this with npm, maven has somewhere over a million packages.

jondubois 9y ago
Well npm requires you to login through their CLI in order to publish packages... The only difference is that you use a password instead of a key. No difference.
- camus2 9y ago
  > Well npm requires you to login through their CLI in order to publish packages... The only difference is that you use a password instead of a key. No difference. Yes, there is a difference, released must be digitally signed on maven. They are not on NPM, so a hacker can hijack your packages just by obtaining your npm credentials. That's crypto 101 and you can't tell the difference?
  - KirinDave 9y ago
    > so a hacker can hijack your packages just by obtaining your npm credentials. Couldn't they 'just' steal your GPG key as well? If someone can trivially steal a strong password from you, I'd worry about key material as well. > That's crypto 101 and you can't tell the difference? Please reconsider sentences like these.
    - sloppycee 9y ago
      The issue is of who to trust, the package maintainer or the package repository? It is comparatively trivial to steal a strong password when it is transmitted over the internet vs local key material. Nation states with bad certs (china has done this) can steal your password, npm can steal your password, npm can be hacked and leak passwords, npm can be subject to a NSL and forced to hand over passwords, etc, etc. There is a big difference between passwords and keys.

tomc1985 9y ago

Yeah I'm not really following how users desiring a natural-language tuple-looking thing prevents proper identity verification. Even without namespacing strong identity controls (signature verification and preventing unauthorized accounts from posting under a taken name, for example) can prevent most attacks short of typosquatting.

stupidcar 9y ago
Typosquatting is exactly what these malicious packages were doing. So you're agreeing that arguments re. identify verification is a useless distraction in this case?
KirinDave 9y ago
You seem to have a handle on every aspect of this situation except what the actual attack we're discussing was. It was typo squatting.
- tomc1985 9y ago
  And you like to assume things. Name canonicalization gets you part of the way there. But unless you want to go full-on namespacing then you must realize you are fighting a pointless battle. You cannot reasonably expect to save users from themselves in every way.
  - KirinDave 9y ago
    Npm has namespacing.

lmm 9y ago

> 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). The hash naturally changes with every release. The key fingerprint doesn't. Updating your dependencies to new releases is much, much more frequent than adding a new dependency; people are willing to put more effort into the latter than the former. > You aren't even in Keybase. Have you personally participated in any keysigning parties? Can I find your public key details here? Keybase encourages poor practices and as such I avoid it. But I've been to keysigning parties and my key's details are published any number of places. (Since adding one more is all to the good, the fingerprint is 400A C7D2 E7A1 802A AE2C C459 B1E5 712A 6D03 3D61)

KirinDave 9y ago
I don't understand why you feel that the keybase question was directed at you. The decision to enter into this part of the discussion definitely hurt otherwise interesting post. It's true that a signature is based around a component with longer lifespan than a hash. However the management and trust of that component damages this argument severely. I am unaware of any web of trust in active use that could operate a npm scale existing today. Could you share one with me?
- graphememes 9y ago
  Because it was a direct reply to the individual. If used as an example you should give context, otherwise your comments are directed towards who you reply to.
  - KirinDave 9y ago
    I didn't reply to lmm. I asked that question of danjoc. Is that not obvious from scrolling?