NPM Install Everything, and the Complete and Utter Chaos That Follows
boehs.orgThe one that ends up looking worse from all of this is Github, followed by NPM. You shouldn't feel guilty about any of the things you did. You did nothing wrong.
> “How can this sort of event that makes our customers angry be prevented in the future?”, they asked themselves. Their answer was a new rule: any versions of a package that has dependents cannot be removed from the registry
> We tried to hang a pretty picture on a wall, but accidentally opened a small hole. This hole caused the entire building to collapse.
These two snippets say everything that needs to be said about the JavaScript ecosystem and mentality. I'll leave if for you to decide what that is.
Do they? Someone tried to solve a large problem with the package manager, and inadvertently created a larger problem. That simply indicates the folks at NPM didn't fully think through the edge cases of their problem/solution.
I'm curious if other package managers have the same problem identified by the author, or are susceptible to the "left-pad" problem?
On crates.io you can't unpublish a crate, you can only yank[1], which marks a package version as unusable as a new dependency. Existing dependencies on it will continue to work though, and it's still publicly available.
"This hole caused the entire building to collapse" is really overstating things since a package depending on all versions of all packages in npm results in the same behavior, which lots of people believe should be how npm should be treating publishing anyways.
The people who were mad were the tiny number of people who expected unpublishing to work, tried to unpublish during that week or two and found it unavailable.
[1] https://doc.rust-lang.org/cargo/commands/cargo-yank.html
Don't sweat a huge faceless entity misrepresenting a cool hack. It's probably a badge of honor among hackers.
Besides, between the words of a random person and a multi-billion corporation, what one should believe is quite obvious.
But moderation frameworks in general suffer from this problem, where people just throw baseless accusations around, pigeonhole behaviors into small crimes, and publish calumnious claims. It's quite obvious why those problems appear, and why communities often end-up hating moderators. What isn't obvious is how to solve it.
Thank you for your encouragement. I actually had to think about if I should post this on my blog, because despite being cool, it was also pretty terrifying. Interestingly, it seems HN moderators don't like it either[0] ¯\_(ツ)_/¯.
[0]: https://github.com/vitoplantamura/HackerNewsRemovals?tab=rea...
Hi HN!! I’m the author of this, if you have questions let me know
Great work! Package management and supply chain issues are definitely something which have by no means been solved. I appreciate that you did your experiment as it pushes the community forward to think solutions to these problems.
I think you should still build some kind of script to install every available package and then do some interesting analysis from the result. For example I'm sure there are supply chain troijan horses awaiting to be discovered.
Yeah. We were considering it, obviously that may have been a better way to go about it. I want to return to it in the future and do it this way, but we lost a little interest after all this.
One of the lessons from the old book the design of everyday things is that when someone uses an artifact incorrectly, it is not the fault of the user but instead the fault of the designer who allowed such a use.
One of the examples in the books are people who keep on pulling on a handle on a door that's meant to be pushed on when the handle looks like a pull handle.
You did nothing other than pull on the pull handle. That the door frame came out of the wall is not your fault.
You mentioned contacting the security teams, was that/did you try HackerOne? I don't think they would allow you to try to deliberately do it from the outset (the preferred reproduction would surely be 1. Create package A; 2. Create package B via another owner; 3. Demonstrate that B rendered A un-unpublishable^) but you might have had more luck explaining that you stumbled into it and need help unwinding it there.
Funny idea, dumb policy, nice write-up!
^In the article you write 'immutable', but I think you mean that it can't be unpublished/de-listed? I suppose definitions vary you could call that immutable, but to me the versions are always immutable so that implies no new version could be published which I don't think was the case?
Big thread at the time, a couple of months ago: https://news.ycombinator.com/item?id=38894445
Thanks, I (TFA author) missed this thread.
Is the NPM server code open (to viewing AND contributions)? I tried looking but couldn't find it anywhere. It would be very weird for something so essential to the OSS community to be closed off and untransparent like this, especially when it's intrinsically tied to the ecosystem of a programming language.
Nice work, a somewhat hilarious, albeit understandably stressful way to surface a few systematic issues.
„Unforeseen Consequences“