4 ms·

For one, they've marked the issue as resolved before they've completed any forensic analysis to discover if additional compromised packages were uploaded with s

For one, they've marked the issue as resolved before they've completed any forensic analysis to discover if additional compromised packages were uploaded with stolen credentials during the window in which they weren't revoked. This gives the false sense that its safe to install packages again.

throwaway5752 8y ago
And the fact they don't get this is incredibly disconcerting.
- mirashii 8y ago
  There's also no systemic fix for this issue. Next week, the same thing could happen again. It's time to enforce two-factor authentication for publishing packages. It's time to publish a roadmap towards package signing and verification. It's time to talk about sandboxing the install scripts to prevent token theft. We're done for the day is so far from sufficient.
  - deleted 8y ago
    [deleted]
  - nanodeath 8y ago
    > package signing and verification You're the first person I've seen mention this, which seems like it should be the first and most obvious line of defense against bad stuff like this. +1
    - smt88 8y ago
      People mention most of these steps every time npm fucks up (which is often). Package management is a mostly solved problem, but npm refuses to learn from the 30+ years of experience that Linux and other communities have had.
      - eropple 8y ago
        I used to be one of the biggest HN proponents of dunking on Node. I would give it a thrashing second only to the windmill dunks I would line up on Go. These days, with ES6, TypeScript, and React...it's actually all pretty nice. But NPM is still and forever a mess that just plain didn't learn from its predecessors--and my only guess as to the cavalier treatment of security issues is that the NPM crew's a bunch of premillenial dispensationalists banking on getting raptured (or bought, I guess, but that's way less fun) before the chickens come home to roost, 'cause just about anything else seems implausible. I am thinking about getting in on Deno only and strictly because maybe that can have a package management solution that is not held captive by an irresponsible venture-backed entity. It's not like anyone's breaking NPM's grip anytime soon. (Even if you tried, their API is so awful as to be functionally incompatible unless you literally just copy their internal structure, so...yeah. Great. Hooray.)
        whatcanthisbee 8y ago
        > ES6, Typescript, React NodeJS didn't make those - they'd be around with any nodejs alternative. btw, nodejs should provide some "isolated" mode (ie run as user "nobody-projectName-userName" - eg. "nobody-react-whatcanthisbee") and do some appropriate group permissions. basic linux permissions can do a lot...
        dvfjsdhgfv 8y ago
        what saddens me is that there seems to be no way out. There are so many projects that worked fine in the past and now the're using npm, for example PhoneGap.
      - hyperpape 8y ago
        Signing packages works well for a linux distro. It's much less clear that it would help for a language package manager: https://caremad.io/posts/2013/07/packaging-signing-not-holy-grail/ https://caremad.io/posts/2013/07/packaging-signing-not-holy-....
        mirashii 8y ago
    - mustacheemperor 8y ago
      In fact, there's a pull request from 2013 for GPG package verification. It took over a year for a response from NPM, shooting it down. There's already an "I told you so" in the thread.[0] >Thank you for your time and effort. Yeah, thanks to you too, NPM. No time or effort to go around for progress on this issue in the interim 3 years, apparently. [0]https://github.com/npm/npm/pull/4016#issuecomment-76316744 https://github.com/npm/npm/pull/4016#issuecomment-76316744
  - crashedsnow 8y ago
    If the hacker has your password, don't they also have the ability to publish a public key used to verify the signed package? It presumably would protect against distribution of a fake package outside of NPM, but if your NPM account is hosed isn't it too late?
    - mirashii 8y ago
      If 2fa is enforced, having your password doesn't get you anything. Publishing an npm package isn't having a Twitter account, it's one of those things where enforcing 2fa shouldn't even be a usability question.
      - Already__Taken 8y ago
        how does 2fa work with auto publishing CI pipelines?
    - kbenson 8y ago
      Not necessarily. Have NPM store the public key, and require a lot of red tape and time to update it (versioning with delays). Require multiple keys to sign or vouch for a package before publishing is complete (log of reverse dependencies +1 maybe). There are lots of options.
  - bodas 8y ago
    I don't think sandboxing install scripts will help much, as any code in the package will be executed when that package is require()'d. You really need to sandbox the whole of `node`.

throwaway5752 8y ago

And the fact they don't get this is incredibly disconcerting.

mirashii 8y ago
There's also no systemic fix for this issue. Next week, the same thing could happen again. It's time to enforce two-factor authentication for publishing packages. It's time to publish a roadmap towards package signing and verification. It's time to talk about sandboxing the install scripts to prevent token theft. We're done for the day is so far from sufficient.
- deleted 8y ago
  [deleted]
- nanodeath 8y ago
  > package signing and verification You're the first person I've seen mention this, which seems like it should be the first and most obvious line of defense against bad stuff like this. +1
  - smt88 8y ago
    People mention most of these steps every time npm fucks up (which is often). Package management is a mostly solved problem, but npm refuses to learn from the 30+ years of experience that Linux and other communities have had.
    - eropple 8y ago
      I used to be one of the biggest HN proponents of dunking on Node. I would give it a thrashing second only to the windmill dunks I would line up on Go. These days, with ES6, TypeScript, and React...it's actually all pretty nice. But NPM is still and forever a mess that just plain didn't learn from its predecessors--and my only guess as to the cavalier treatment of security issues is that the NPM crew's a bunch of premillenial dispensationalists banking on getting raptured (or bought, I guess, but that's way less fun) before the chickens come home to roost, 'cause just about anything else seems implausible. I am thinking about getting in on Deno only and strictly because maybe that can have a package management solution that is not held captive by an irresponsible venture-backed entity. It's not like anyone's breaking NPM's grip anytime soon. (Even if you tried, their API is so awful as to be functionally incompatible unless you literally just copy their internal structure, so...yeah. Great. Hooray.)
      - whatcanthisbee 8y ago
        > ES6, Typescript, React NodeJS didn't make those - they'd be around with any nodejs alternative. btw, nodejs should provide some "isolated" mode (ie run as user "nobody-projectName-userName" - eg. "nobody-react-whatcanthisbee") and do some appropriate group permissions. basic linux permissions can do a lot...
      - dvfjsdhgfv 8y ago
        what saddens me is that there seems to be no way out. There are so many projects that worked fine in the past and now the're using npm, for example PhoneGap.
    - hyperpape 8y ago
      Signing packages works well for a linux distro. It's much less clear that it would help for a language package manager: https://caremad.io/posts/2013/07/packaging-signing-not-holy-grail/ https://caremad.io/posts/2013/07/packaging-signing-not-holy-....
      - mirashii 8y ago
  - mustacheemperor 8y ago
    In fact, there's a pull request from 2013 for GPG package verification. It took over a year for a response from NPM, shooting it down. There's already an "I told you so" in the thread.[0] >Thank you for your time and effort. Yeah, thanks to you too, NPM. No time or effort to go around for progress on this issue in the interim 3 years, apparently. [0]https://github.com/npm/npm/pull/4016#issuecomment-76316744 https://github.com/npm/npm/pull/4016#issuecomment-76316744
- crashedsnow 8y ago
  If the hacker has your password, don't they also have the ability to publish a public key used to verify the signed package? It presumably would protect against distribution of a fake package outside of NPM, but if your NPM account is hosed isn't it too late?
  - mirashii 8y ago
    If 2fa is enforced, having your password doesn't get you anything. Publishing an npm package isn't having a Twitter account, it's one of those things where enforcing 2fa shouldn't even be a usability question.
    - Already__Taken 8y ago
      how does 2fa work with auto publishing CI pipelines?
  - kbenson 8y ago
    Not necessarily. Have NPM store the public key, and require a lot of red tape and time to update it (versioning with delays). Require multiple keys to sign or vouch for a package before publishing is complete (log of reverse dependencies +1 maybe). There are lots of options.
- bodas 8y ago
  I don't think sandboxing install scripts will help much, as any code in the package will be executed when that package is require()'d. You really need to sandbox the whole of `node`.