Live data from Hacker News

Npm operational incident, 6 Jan 2018

blog.npmjs.org

151–160 of 197 posts

Re: Npm operational incident, 6 Jan 2018

#151
post #138

Earlier quoted context omitted.

> and anyone who was using my "order_pizza" will now silently get the other developer's "order_pizza" the next time they build. Nope.

What if the project that requires order_pizza has no restriction on what version it pulls in?

  - It still wouldn't be silent or automatic
  - npm-based projects have a package lock

Re: Npm operational incident, 6 Jan 2018

#153

Earlier quoted context omitted.

It's almost as if the tech community has to learn once again centralized systems with a trusted authority at the top can't be trusted when that trusted authority makes mistakes.

Honest question: what's the alternative?

nix (pkg manager). Can give you an insane amount of control of how your project builds, especially if you use nixos, but with great power comes great responsibility XD.

Re: Npm operational incident, 6 Jan 2018

#154
post #133
post #110

From what I've read (I've not yet worked on anything that used npm), it appears that npm uses a single shared flat namespace for all packages. If I publish a package named "order_pizza" nobody else can name a package "order_pizza", unless mine gets deleted first, and then they can...and anyone who was using my "order_pizza" will now silently get the other developer's "order_pizza" the next time they build. Anyone kno…

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

That is a new facility.

Re: Npm operational incident, 6 Jan 2018

#155
post #110

From what I've read (I've not yet worked on anything that used npm), it appears that npm uses a single shared flat namespace for all packages. If I publish a package named "order_pizza" nobody else can name a package "order_pizza", unless mine gets deleted first, and then they can...and anyone who was using my "order_pizza" will now silently get the other developer's "order_pizza" the next time they build. Anyone kno…

I think it's annoying but also toxic to an ecosystem. You have to name your packages the same way you look for a domain name, people can squat on names, and it causes drama like how the 'kik' package was stolen from a developer and given to a company who never used it. Nobody would've cared it the package was "tzs/kik". For example, the Elm package system does this right. Another example of this failure is the Reddit…

The failure is yours alone if you actually consider Reddit an authority on anything.

Re: Npm operational incident, 6 Jan 2018

#156
post #41

Earlier quoted context omitted.

My first thought was “What about including node_modules in your version control?” Downside is that the repo would be much larger, but if it’s going to expand to that size on the client after running “npm install”, maybe that’s not a big deal? But it feels kinda wrong to do that...

That would break when going cross platform for modules with native deps.

See npm rebuild https://docs.npmjs.com/cli/rebuild

Re: Npm operational incident, 6 Jan 2018

#157
post #92

Earlier quoted context omitted.

Are you saying that displaying a Bible quote, modified to refer to the fact that duplexer3 is gone, is "malicious"? I believe this was one of the cases of a community member stepping up to publish a package quickly so that malicious code wasn't published. Presumably they make the claim that none of the code was malicious because they checked.

from the blog post: > the integrity of these 106 packages were never jeopardized. are we operating with different definitions of jeopardy here? 106 packages were absolutely at risk of harm during this window. The fact that some community members stepped up is irrelevant, a bad actor could have done a lot of damage here. I think this blog post is completely disingenuous, and doesn't make me trust npm.

I was replying to 0x0's claim, not making a broad statement about npm's policies.

0x0 claimed the code uploaded as duplexer3 was "undesirable code" and implied that it was a "malicious actor". It was completely utterly benign.

Re: Npm operational incident, 6 Jan 2018

#158
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…

Do you suppose FB+Yarn is in a position to compete? Yarn can implement support for optional package signing. From the consumer's perspective, one can choose to be alerted whenever the "main" package signer (usu. developer) changes, or simply to accept only packages verified and signed by a group of trusted third parties.

Re: Npm operational incident, 6 Jan 2018

#159
post #68
post #59

Earlier quoted context omitted.

> 1. As a developer I can not know with certainty that a package I publish will remain published under its current name. You can as long as your package name isn't trademarked or likely to confuse users installing the package. > 2. As a consumer of packages I can not trust that a library I am using won't get changed to a different piece of code due to someone else thinking they deserve the name better. I'm actually f…

>> 1. As a developer I can not know with certainty that a package I publish will remain published under its current name. > You can as long as your package name isn't trademarked or likely to confuse users installing the package. Trademarked where exactly? You know, there's quite a lot of world beside US. > I'm actually fairly sure npm won't blindly hand over a package that is depended upon, to another entity. What m…

>>> 1. As a developer I can not know with certainty that a package I publish will remain published under its current name.

>> You can as long as your package name isn't trademarked or likely to confuse users installing the package.

> Trademarked where exactly? You know, there's quite a lot of world beside US.

And, if I recall correctly, trademarked when? Wasn't leftpad.js's author using the name kik well before the company Kik existed? So you don't just need a name that's not trademarked _now_, you need to pick one that no-one else trademarks sometime in the future (in whatever jurisdictions the npm people care about)...

Re: Npm operational incident, 6 Jan 2018

#160
post #86
post #68

Earlier quoted context omitted.

>> 1. As a developer I can not know with certainty that a package I publish will remain published under its current name. > You can as long as your package name isn't trademarked or likely to confuse users installing the package. Trademarked where exactly? You know, there's quite a lot of world beside US. > I'm actually fairly sure npm won't blindly hand over a package that is depended upon, to another entity. What m…

> and their behaviour up until now slightly suggests the opposite. Please elaborate. Afaik 'kik' wasn't significantly depended upon, and people using the old kik could still install it [1] (had the leftpad author not unpublished it), and that is the only example I'm aware of of npm handing over a package name. [1] http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm

Pretty sure "allover" isn't "significantly depended upon" - how would you feel if YC gave that account here to me just because I went and paid for a trademark on it?
Post reply on HN