7 ms·

This is a good post-mortem with clear, policy-based remediations. Nicely done. I wonder why they are only preventing republishing for 24 hours. Is there a good

by bhuga 9y ago

This is a good post-mortem with clear, policy-based remediations. Nicely done. I wonder why they are only preventing republishing for 24 hours. Is there a good reason to allow a package namespace to be recycled with less than, say, a week? Is it based on the assumption that the only case where it comes up is during an incident, and 24 hours is enough time to assume an incident will be resolved? I'm curious what went in to that number.

smt88 9y ago
Why allow namespace recycling at all? The potential harm is high and the potential benefit is some slight convenience. If npm packages used a Github-style "author/package" format, name collision would never be an issue again.
- JonathonW 9y ago
  I'd like to see a package registry with (1) Github-style author-namespaced packages, and (2) package signing (i.e. if an author starts signing packages with a different key, I'd like to know about it). Maybe integrate the latter with Keybase to help users decide if they should trust a key. I don't know how you gain any kind of critical mass trying to compete against a well-established registry like npmjs, though.
  - colanderman 9y ago
    Package signing by the author helps, but not if (a) the author's key is compromised, or (b) the author acts in bad faith. With npm-style package registries, the risk of such an event increases with the number of dependencies your project has. Better to (a) ship your code with explicit version and content dependencies (e.g. a SHA-256 of the package you expect to exist), or (b) delegate trust in upstream packages to fewer, more well-vetted, authorities (i.e. distro-style).
  - hyperpape 9y ago
    (1) has the consequence that names are associated with the original creator long after they may no longer be involved. Package signing I can't tell if it's a good idea or not. It would require you to accept a new key in this case, but that is going to happen super frequently with NPM, inducing alert fatigue, and it doesn't do anything to prevent the authors' publishing credentials getting stolen.
    - philipwhiuk 9y ago
      (1) big projects just get moved over time. e.g. philipwhiuk/gnome moves to gnome/core and there's a version published to philipwhiuk/gnome that pulls in gnome/core
  - sitkack 9y ago
    I'd also like a bunch of checks applied to my use of that registry. 1. only packages > nK downloads 2. only packages with tests 3. only packages with publicly available code that is same that I am downloading 4. only packages with > nnn stars, forks, issues, pull requests All are just proxies for being a valid node in a dependency graph. And like to know if any transitive dep violates my inclusion rules.
- colanderman 9y ago
  When your code deployment model is effectively "download stuff from random websites", I feel like namespace recycling is the least of your worries. (That is to say, trusting that any given named package that `npm install` downloads is what you think it is is really no different that trusting `wget https://example.com/thecode.tgz` https://example.com/thecode.tgz`. Even if you verify that the domain hasn't switched hands, you have no guarantee that the author's pipeline wasn't compromised, or that the author didn't add malware themselves. There's a reason Debian, Red Hat et. al. put a lot of effort into ensuring integrity of their repositories.)
- Klathmon 9y ago
  >If npm packages used a Github-style "author/package" format, name collision would never be an issue again. They have that, and many are finally starting to take advantage of it (with babel being the most prominent with their latest version) But this doesn't completely "fix" the problem, since the exact same conflicts can still happen with the "author" name (if someone takes "google\" there are going to be some very upset californians)
  - slig 9y ago
    > (if someone takes "google\" there are going to be some very upset californians) Not a problem at all. They will just get the name by force. It already happened before, google "npm kik".
    - Klathmon 9y ago
      Yeah, but it's still a "problem" in that it technically doesn't change anything from the current system.
  - ohitsdom 9y ago
    It does fix the problem, although consumers of the package need to first verify they trust the original author. For example, if Google published "Google/polymer", dependents would be unaffected if a new package was published from "badguy/polymer". I think you're saying it's still not fixed because someone could register the Google author name before the real Google gets it, but that is a understood problem across every website.
  - krapp 9y ago
    >But this doesn't completely "fix" the problem, since the exact same conflicts can still happen with the "author" name (if someone takes "google\" there are going to be some very upset californians) The idea is that the author name maps to an actual repo and should serve as a second layer of authentication outside of NPM's control. The namespace should belong to the repository owner. No one should be able to "take" google/ since the actual Google already owns github.com/google.
- Ajedi32 9y ago
  Seems like they're only allowing name reuse in the case of spam packages. Not allowing name reuse in that case might result in lots of names being rendered permanently unusable by automated spambots. Assuming no actual users are depending on packages which are literally just spam, I don't really see an issue with reusing the names of those packages.
- pmarreck 9y ago
  You already sound smarter than whoever leads the Node Package Mess.
- parenthephobia 9y ago
  I think package URIs should include a secure hash of their contents. Although you won't get updates without asking for them - I'm not sure that's a bad thing - you can be assured that you'll either get the package you were expecting or no package at all.
detaro 9y ago
They allow deletion of packages for 24 hours without staff involvement, there is nothing said about a time limit on republishing after deletion?
- bhuga 9y ago
  From the response steps: > Our first action, which began immediately after the incident concluded, was to implement a 24-hour cooldown on republication of any deleted package name.
  - aidenn0 9y ago
    But they also have a policy of replacing deleted package names with placeholders, which was not currently enforced for spam-deletions. The cooldown should give them 24 hours to discover any remaining holes in that policy.
  - detaro 9y ago
    Oops, missed that part. Guess the logic is that for spam-packages, there isn't going to be anyone relying on them and it would be a waste of namespace space to allow spammers to fill it up?
    - mbessey 9y ago
      Yes, and there are dozens of spam packages registered (and deleted) every day.

by bhuga 9y ago

smt88 9y ago

Why allow namespace recycling at all? The potential harm is high and the potential benefit is some slight convenience. If npm packages used a Github-style "author/package" format, name collision would never be an issue again.

JonathonW 9y ago
I'd like to see a package registry with (1) Github-style author-namespaced packages, and (2) package signing (i.e. if an author starts signing packages with a different key, I'd like to know about it). Maybe integrate the latter with Keybase to help users decide if they should trust a key. I don't know how you gain any kind of critical mass trying to compete against a well-established registry like npmjs, though.
- colanderman 9y ago
  Package signing by the author helps, but not if (a) the author's key is compromised, or (b) the author acts in bad faith. With npm-style package registries, the risk of such an event increases with the number of dependencies your project has. Better to (a) ship your code with explicit version and content dependencies (e.g. a SHA-256 of the package you expect to exist), or (b) delegate trust in upstream packages to fewer, more well-vetted, authorities (i.e. distro-style).
- hyperpape 9y ago
  (1) has the consequence that names are associated with the original creator long after they may no longer be involved. Package signing I can't tell if it's a good idea or not. It would require you to accept a new key in this case, but that is going to happen super frequently with NPM, inducing alert fatigue, and it doesn't do anything to prevent the authors' publishing credentials getting stolen.
  - philipwhiuk 9y ago
    (1) big projects just get moved over time. e.g. philipwhiuk/gnome moves to gnome/core and there's a version published to philipwhiuk/gnome that pulls in gnome/core
- sitkack 9y ago
  I'd also like a bunch of checks applied to my use of that registry. 1. only packages > nK downloads 2. only packages with tests 3. only packages with publicly available code that is same that I am downloading 4. only packages with > nnn stars, forks, issues, pull requests All are just proxies for being a valid node in a dependency graph. And like to know if any transitive dep violates my inclusion rules.
colanderman 9y ago
When your code deployment model is effectively "download stuff from random websites", I feel like namespace recycling is the least of your worries. (That is to say, trusting that any given named package that `npm install` downloads is what you think it is is really no different that trusting `wget https://example.com/thecode.tgz` https://example.com/thecode.tgz`. Even if you verify that the domain hasn't switched hands, you have no guarantee that the author's pipeline wasn't compromised, or that the author didn't add malware themselves. There's a reason Debian, Red Hat et. al. put a lot of effort into ensuring integrity of their repositories.)
Klathmon 9y ago
>If npm packages used a Github-style "author/package" format, name collision would never be an issue again. They have that, and many are finally starting to take advantage of it (with babel being the most prominent with their latest version) But this doesn't completely "fix" the problem, since the exact same conflicts can still happen with the "author" name (if someone takes "google\" there are going to be some very upset californians)
- slig 9y ago
  > (if someone takes "google\" there are going to be some very upset californians) Not a problem at all. They will just get the name by force. It already happened before, google "npm kik".
  - Klathmon 9y ago
    Yeah, but it's still a "problem" in that it technically doesn't change anything from the current system.
- ohitsdom 9y ago
  It does fix the problem, although consumers of the package need to first verify they trust the original author. For example, if Google published "Google/polymer", dependents would be unaffected if a new package was published from "badguy/polymer". I think you're saying it's still not fixed because someone could register the Google author name before the real Google gets it, but that is a understood problem across every website.
- krapp 9y ago
  >But this doesn't completely "fix" the problem, since the exact same conflicts can still happen with the "author" name (if someone takes "google\" there are going to be some very upset californians) The idea is that the author name maps to an actual repo and should serve as a second layer of authentication outside of NPM's control. The namespace should belong to the repository owner. No one should be able to "take" google/ since the actual Google already owns github.com/google.
Ajedi32 9y ago
Seems like they're only allowing name reuse in the case of spam packages. Not allowing name reuse in that case might result in lots of names being rendered permanently unusable by automated spambots. Assuming no actual users are depending on packages which are literally just spam, I don't really see an issue with reusing the names of those packages.
pmarreck 9y ago
You already sound smarter than whoever leads the Node Package Mess.
parenthephobia 9y ago
I think package URIs should include a secure hash of their contents. Although you won't get updates without asking for them - I'm not sure that's a bad thing - you can be assured that you'll either get the package you were expecting or no package at all.

detaro 9y ago

They allow deletion of packages for 24 hours without staff involvement, there is nothing said about a time limit on republishing after deletion?

bhuga 9y ago
From the response steps: > Our first action, which began immediately after the incident concluded, was to implement a 24-hour cooldown on republication of any deleted package name.
- aidenn0 9y ago
  But they also have a policy of replacing deleted package names with placeholders, which was not currently enforced for spam-deletions. The cooldown should give them 24 hours to discover any remaining holes in that policy.
- detaro 9y ago
  Oops, missed that part. Guess the logic is that for spam-packages, there isn't going to be anyone relying on them and it would be a waste of namespace space to allow spammers to fill it up?
  - mbessey 9y ago
    Yes, and there are dozens of spam packages registered (and deleted) every day.