Live data from Hacker News

Npm operational incident, 6 Jan 2018

blog.npmjs.org

161–170 of 197 posts

Re: Npm operational incident, 6 Jan 2018

#161
Has the community discussed adding cryptographic signatures to npm packages? It's generally a good idea in any case, but this outage further highlights the security risks of a public registry where packages are not signed.

Re: Npm operational incident, 6 Jan 2018

#162
post #133

Earlier quoted context omitted.

Organizations on npm can publish "namespaced" modules, that look like `@orgName/moduleName`. It's just optional.

That is a new facility.

This npm blogpost about them was published almost three years ago: http://blog.npmjs.org/post/116936804365/solving-npms-hard-pr...

Re: Npm operational incident, 6 Jan 2018

#164

Independent of npm's issues now and in the past, how vulnerable are other package managers to similar problems? There were typosquatting issues with pip, replacement issues with Rubygems, probably others that I don't recall. What's the current state of things for the more commonly used languages?

Maven/Gradle don't allow un-namespaced packages; nobody knows for sure how deep up their arse npm's designers have had their ass when they made non-namespaced packages possible (even the only way in the beginning; I don't know if it's still the default).

Additionally, there's the problem of npm's fine-grained dependencies (that have become a laughing stock in itself), in my Java large projects, while I don't know every single dependency, I know all the "vendors", i.e. trusted upstream namespaces I use, and their transitive dependencies. There's the occasional non-Eclipse, non-Google, non-Apache dependency (say, XStream), but I am aware of it and fix it to a specific version. npm with its thousands of dependencies by hundreds of pseudonymous developers for simple projects is an abomination.

Re: Npm operational incident, 6 Jan 2018

#165
post #5

"We don’t discuss all of our security processes and technologies in specific detail for what should be obvious reasons..." - Security by obfuscation? That's not security. Your protocols and processes should stand up even if made public.

What is your home address and phone number?

If you think that your address and phone number are secret information, consider how easy it would be to find yours from the information in your HN profile. I'm pretty sure I found your entry on whitepages within a few minutes and I'm barely motivated to find it.

Re: Npm operational incident, 6 Jan 2018

#166
post #80
post #37

I've used NPM only a little but this scares me. What are NPM alternatives?

NPM shouldn't scare you. Simple fact is you should not be relying on ANY package registry at the time of deployment.

These days we deploy whole virtual machines from image reopsitories.

Re: Npm operational incident, 6 Jan 2018

#167
post #5

Earlier quoted context omitted.

What is your home address and phone number?

If you think that your address and phone number are secret information, consider how easy it would be to find yours from the information in your HN profile. I'm pretty sure I found your entry on whitepages within a few minutes and I'm barely motivated to find it.

I think you are confused as to my intention

Re: Npm operational incident, 6 Jan 2018

#168
post #167

Earlier quoted context omitted.

If you think that your address and phone number are secret information, consider how easy it would be to find yours from the information in your HN profile. I'm pretty sure I found your entry on whitepages within a few minutes and I'm barely motivated to find it.

I think you are confused as to my intention

I thought you were asking a rhetorical question to show that obfuscation is a valid security measure that we all use. What was your intention?

Re: Npm operational incident, 6 Jan 2018

#169
post #14

> Unfortunately, the process was complicated by well-meaning members of the npm community who believed that a malicious actor or security breach was to blame and independently attempted to publish their own replacements for these packages. Ensuring the integrity of the affected packages required additional steps and time. That is such a bad response to this. The problem isn't that "well-meaning members of the communi…

It's been literally years since node-forward got its talk about signing packages [1] with a lot of pushback from the npm team. Every time a new typosquatting article shows up, there's some more waffling by npm. left-pad happened to much consternation. Now this. I used to really care about trying to harden the Node ecosystem, and last year it was one of my main goals. I tried to send multiple vulnerability reports, do…

This is your occasional reminder that package signing is not a panacea, and as typically proposed for community package repositories like npm, PyPI, etc. would likely do absolutely nothing.

For example, people often insist in the Python world that PyPI should support package signing. But it already does -- you can generate a signature for a package and upload the signature with the package. Django does this, and has been doing it for years. You can also get package download/install tools that will check the signature. But then what?

What people really mean when they say there should be "signed packages" is that there should be a whole bunch of invisible infrastructure (set up by... who, exactly? Maintained by... who, exactly?) to decide which PGP keys are authorized to sign releases of which packages. And that's close to an intractable problem for an anyone-can-contribute community repository like npm or PyPI.

Post reply on HN