How One Command Broke NPM
Вставка
- Опубліковано 5 вер 2024
- Man this was a lot of work. I'm sad that "unpublish" is as fragile as it is, but please don't harass anyone over this.
Check out Trash's UA-cam channel @trash_dev
Or his twitter / trashh_dev
Or Patrick's twitter / patrickjs__
Check out my Twitch, Twitter, Discord more at t3.gg
thanks for telling the story so well ❤️❤️
shoutout patrick, uncenter, hacksore, boehs, picklenik
Shut up nerd
Damn Theo😂
Eww, it's you haha. Please break something else 🤑. It is so funny watching script kiddies crying because no please man goes down...
The fact that you were called a bad actor by github when actual reported malware is able to stay up on github is wild.
You're amazing, I love you and *everything* 😏
Imagine if a company blamed security researchers for finding vulnerabilities in their software, and instead of fixing the bug, they suggest a workaround that ignores the problem. Such is the life of the NPM ecosystem in JS land. Sadge
It sounds like they didn’t create a workaround, they instead got the project nuked off of GitHub and called it a day
MC Donald's be like: the meme with the puppet looking at the viewer and then back straight.
ok but this happens more often then you would like. This is why a lot of security researchers have a lawyer and a public disclosure policy. You need to hold companies ransom in order for them to fix their shit far too often.
This literally what Cisco did when a security researcher found an issue with SMTP, called SMTP smuggling. Cisco "Secure" Email is vulnerable, but the feature responsible for causing SMTP smuggling is their default, so they won't change it.
i mean in germany you can get straight sued for finding vulnerabilities and telling them about it
"We're not reasonable, we're JavaScript developers"
this has to be the best line anyone has ever said
put it on a t-shirt
this line goes for any dev ngl.
It's ironic that a lot of JS devs can't take a joke when the entire JS ecosystem is literally a giant one.
I recently saw a guy that said he wrote a python server THAT DELETES HIS NODE_MODULES FOLDER EVERY 5 MINS. And reinstalls everything.
Apparently not doing that causes some sort of problem.
That’s fucking hilarious.
I mean, it’s hilarious from my POV because I use Python and Im unaffected by this. But if I were to use JS, I would hate the ecosystem and tooling
@DigitalSwirls why?
Tweet this, tag primeagen
Can someone please explain to me why, and give an example of a good ecosystem? (Apparently, python of all things)? Working with node for 4 years and I never had issues with js/ts ecosystem.
How are people blaming anyone but NPM for this? If anything, this meme project did everyone a favour in bringing exposure to such a major issue with NPM.
It's not a major issue. If I would be NPM, I would just ban those users forever and unpublish everything.
@@guseynismayylov1945 That doesn't solve the underlying issue at all though, and wrongly punishes those users. And considering the consequences that have occured and how angry some people have gotten, it sure seems like a major issue.
@@ollierkul you can always find loopholes in anything. It’s like rubbing a bank and blaming a bank for that. Sure, banks should be always as secure as possible but does it justify the robbers?
NPM allows you a lot what comes to managing your dependencies, and if that’s their fault, well, it means they put too much trust in people.
About “*”, I think it can be solved in various ways, but I am not an expert of how npm works under the hood.
@@guseynismayylov1945easy… just yeet * out of any new package
@@guseynismayylov1945 You are comparing a joke project with zero malicious intentions to bank robbers.
This is not just a loophole, it's a major oversight that should not exist to begin with. The creators of the project even tried to do everything they could to solve the issue as soon as they realised.
It makes no sense to put all blame on the creators and none on NPM.
The "simple" fix would be to permit unpublishing a package which is depended on via a * if there is at least 1 other available version. That is, if A has published 1.0 and 2.0, and B depends on A: *, the A could unpublish 1.0 or 2.0, but not both. Once A 3.0 is published, then 1.0 and 2.0 could be unpublished, etc .
Anyway, really good summary. NPM needs to actually address the issue.
they just need to remove unpublish feature at all
This wouldn't fix the everything issue I don't think
@@snowwsquire It would prevent packages being completely removed from NPM, so not a perfect solution, but certainly better.
I think if you specify * as the package version, that should mean "any", not "all".
I would even argue that a * dependency shouldn't stop you from unpublishing at all.
Besides that it seems absolutely ludicrous to me to depend on *. To not know what version you are getting sounds like wanting trouble in the future.
Just make it so * dependencies prevent unpublishing any version that was published prior to the package that's taking the dependency on it.
NPM should be THANKING Trash and Patrick for exposing their major system flaws. Now they can get to work fixing it and make NPM better for everyone.
Yes, but you have to realize most javascript developers are short on braincells. Instead of calling out NPM for the piece of shit it truly is, they go after the dude instead.
Evidence to this is the replies in github. The js community over time has accumulated a negative IQ.
I mean hell, how many times has this piece of garbage broken, or hit by supply chain attacks, already over the years, What do they do about it everytime? Either bugger all or worse.
They won't tho, that's the problem
they managed to include all npm dependencies without issues, and here I struggle with peer dependencies while setting up a simple React app
Skill issue
/s
I am working as a React dev for a couple of (around 2) years and have set up dozens of React apps from 0 to production throughout that time, so I want to ask... What the fuck are you talking about? What "simple apps" are you setting up really? This is the first time ever I have even heard the term "peer dependencies". You are either working with outdated technologies or doing something very wrong if you need that for a "simple" app.
@@twothreeoneoneseventwoonefour5 least egotistical react related response
@@flakkkk But nonetheless I am seriously concerned and confused about wtf is that guy doing.
@@christopherkrause337 The guy precisely said: "when setting up a simple React project". He didn't practice anything. He definitely does some weird stuff with wtf he is doing. Also I am pretty sure that your argument doesn't matter in this context.
It seems to me the everything publishers did the node community a favor by accidentally exposing an NPM flaw that could have been taken advantage of by a malicious actor at an opportune moment. It should go w/o saying NPM bears responsibility, but judging from some of the comments in the video -- apparently it needs saying.
I * that
Since it appears that the flaw won’t be fixed, it may overall just have ended up being an inconvenience.
Or the flaw revealed is in npm’s leadership and decision making.
Explain your reasoning.
They basically did white hacking, revealed a big attack vector on NPM and they refused to fix it, can't wait to see this exploited by actual malicious actors over and over, just wait
@@31redorange08 some hacker group discovers a bug in a newly-published version of a common used library. The hacker group uses this star trick to prevent the person from unpublishing. Now many systems might be accidentally vulnerable
I think the fact that this did have so many side effects and that people got so mad makes the joke even funnier 😅
A star dependency should force any one version to remain and be non-unpublishable. It shouldn’t prevent all versions from being unpublished.
There should also be a way to remove a dependency in a package json without changing the version.
Good point. The guy who used star didn't care what version he got, so give them what ever.
Exactly, thats how the dependency is resolved when you actually use it. Star means ‚any‘ there not „please download literally every version of this package and use all at the same time“. So the implementation in unpublish is just straight um inconsistent usage of this identifier.
it's a bingooo
Can't wait to see the Primeagen's reaction on this chaos.
same here
KEKL
😂😂😂
I instantly imagined him kicking his legs and dying of laughter when the part about version * was on, is this ... me being parasocial?
We gonna pretend the Rust registry does better? 😅
Why?
I never knew NPM allowed depending on version "*", and I am horrified that anyone thought that was a good idea.
That the person who added it *knew how unpublishing worked* is just crazy. NPM dropped the ball many times over here.
Yeah, it should use the lock file.
"*" is sometimes useful. I use it in my projects when I want to make sure that I depend on the same version of a package as one of my dependencies.
"My package works with every version of this package past and future" should not be the acceptable setting when you merely want "Use the same version as this deoendency."
Can you choose the latter? That would be great.
There should be a pathway to unpublishing, such as deprecating a package, no?
Isaac, who invented npm, wrote both of those features. "*" came first, IIRC, and unpublish was added before it was stable. But it's not a bug - it's someone going out of their way to abuse the registry's constraints. Anyone who actually did the research on how dependency resolution works and the registry's constraints would've figured that out before publishing `everything`. All that said, anyone not using `save-exact=true` has been doing it wrong for years, there's no good reason to ever depend on loose versions.
Remind Ryan Dahl saying that "it's the cute little thingies you add to your project that bites you the hardest" or something? * is that cute little thingie.
One of my favorite quotes ever
One day I found "no one escape" in the "Dependents" list of my package. It was a git project generating empty packages with a bunch of dependencies. It worked for a few days and then the package disappeared. And somewhere in those days npm was really lagging and sometimes not downloading packages.
While this is definitely on NPM, I can’t shake the feeling that if the joke it wasn’t done by devs with public profiles and friends like Theo or Prime, things would have gone *very* differently…
Me and uncenter are nobodies
The way this should work with star is to check if you have at least one published version, in this way you can publish a new version and unpublish the defective one
That's exactly what I was thinking about. I don't know why npm guys didn't have the same idea, or why it could be hard to implement
Probably because a lock file would reference a specific version
@@BCRooke1 doesn't matter, if they try to run npm i it will fetch the version it has in the registry
What if "*" worked as if it was depending on "@latest" or so?
@@shmloney but a build pipeline should be using npm ci, in which case it’d pull the version from the lock file
That the core issue comes down to NPM forcing kik to be transfered and the damage control, is a good indicator that it perhaps is time to switch to a different manager. NPM doubling down on the everything response just highlights the issue with the decission makers in that company.
do you think people didn't already tried to make a "different manager"? there's thousands out there you can choose from already. you can change the npm CLI (or other package manager tools) to use other registries.
@@dealloc Not a different manager, that wouldn't be able to handle unpublish differently. You'd need to switch to a different registry. Nobody wants to do that because hosting costs money.
Npm shifting blame for their architecture decisions is ridiculous.
People should really learn Hanlon's razor "Never attribute to malice that which is adequately explained by stupidity."
When stupidity comes to extreme, it is same as malice.
@@goose_clueswhat an amazing and insightful comment!
Great video explaining the entire saga! Definitely one of your best videos!
Absolutely love Trash and Patrick for doing this haha, this is insanely funny!
what's exactly funny about that? it's just stupid. Instead of doing something productive and something that requires intellect, they just decided to do another dumb shit.
Imagine all npm packages change their dependencies to version *. This will be the most hilarious meme continuation ever.
Thank you for roasting those rude developers. It's crazy how often that kind of elitist behavior goes around in the development world, and probably in all other communities as well.
super straight forward to fix
1) Map "*" to "latest"
2) latest should always use the latest *published* revision.
3) if for example 1.0.1 gets unpublished, "latest" shall instead point to 1.0.0 instead.
This will still disable the "deletion" of the whole package, but that would still make sense as an package is depending on it.
though, maybe npm wants to just unlist the package from public search / viewage if thats the case.
So I'm a bit confused, did they actually fix the issue? Couldn't someone just do this again but maliciously this time, and persistently too? What is going on over at NPM
There probably would even be a way to automate this. So yeah NPM needs to make * not cause a lockup asap
I'm pretty sure I saw someone doing something similar maliciously now that it's known but not fixed, actually.
Definitely sounds like a bug on the NPM side.
If you depend on version * of a package, all that says is you require at least 1 version of it to exist, not every version of it.
Therefore if your package is a dependency of another package (with version *) they should allow you to unpublish any given version of a package as long as at least 1 still exists.
I am not in coder world at all, and also thought about exact same fix. It's not that anything with "*" dependency will download every version of package that exists, right?>
I guess there should be simple layered check.
1. Ignore any "*" dependency. Is this package version has explicit dependencies onto? Yes - deny unpublish. No - continue to 2
2. Is there any "*" dependency listed? Yes - continue to 3. No - unpublish.
3. Is this version of package only one that exists? Yes - deny unpublish. No - unpublish.
So people can still make everything2 to make the packages unpublishable unless the npm admins take action right?
Loved this chapter format, feel like some backing tracks that change with the chapters would be cool with this format too!
Edit: Also using the Video Chapters feature would be great for this!
I highly considered both. For the music I didn’t feel like putting the time in and i had just wrapped up a copyright dispute so I avoided it. For chapters, they hurt retention and would “spoil” things, might add them in a week or two after initial surge
@@t3dotgg totally get where you’re coming from, either way it’s a good watch, great work
The * dependency sounds dodge as a feature.
It would be very rare that you didn’t care what version you got, or that you somehow need to install all versions.
What the hell goes on in the heads of people like dasdeo and mattlucock? All that happens was that by developing everything they found a bug in NPM and are waiting for NPM to fix this. They didnt plan for this and didnt think this would happen. Some people....
It is irrelevant if they knew this would happen. NPM should protect itself against malicious actors and abuse.
They did it by accident, but what if someone does it intentionally?
And it does not have to be with bad intentions either. You could think: this thing is messed up. Im going to break everything so people notice the problems they are ignoring and force them to fix this madness
They think they're so intelligent, that you can hear their entitlement through their words. When in reality, most likely, they're copy-pasta coding monkeys. Losers like to jump & harass others, often having no idea what the underlying issue is. Still, the ability to blame others (by proxy for jumpers being losers) makes them feel better. If anything, those comments show that the average IQ of js "dev" is not that high - their reading comprehension sucks and that's why most (js) software is abysmally bad.
But it's not an accident. They did it intentionally. The only thing they didn't realise was the * version @@greyshopleskin2315
"They didnt plan for this and didnt think this would happen." you are ignorant and naive, I'm 99% sure they knew EXACTLY what was going to happen. If you ever had to unpublish a package you'll know that you cannot unpublish it if it has dependents in the registry. They WANTED to break npm in order for them to fix it. However, this is not how it should be done. Responsible people will FIRST contact the company in question AND then make their findings public. Why npm has this policy is their decision and if you're using npm you'll have to play by their rules, not yours.
@@MMMMMMarco “Im 99% sure”
Why? Do you know if they knew how the unpublishing policy works? Do you knew they knew what was going to happen?
I'm in awe of the JS community's savant level talent of making old mistakes in new ways
I think it would be interesting for NPM’s unpublish policy to be tested in court - by disallowing creators to remove their own IP I’m pretty sure they will be breaking some copyright laws
You voluntarily post your packages to npm (assuming someone didn't publish your package illegally) so by posting you give npm an indefinite licence to that version of your code.
Aaaand ontop of what Isaac said, you don't want to be sh*tt*ng anywhere near MS...
@@IsaacShoebottommaybe GDPT can help here ?
What if you don't own the IP to what you published? A DMCA takedown would require it to be removed, regardless of the website's policy.@@IsaacShoebottom
@@nicolaicornelis2853 yeah, that would be publishing a package illegally. I'm sure npm has procedures in place for this
NPM doing silly stuff is starting to become a meme in and of itself
Unfortunately no one has figured out anything better, yet. We tried briefly with Entropic, that never took off. No one in the JS world wants to downgrade to something as crappy as Bower or Pip, and for a few years there the npm registry team were truly brilliant.
@@zacanger I remembered seeing a conference talk from Ceej Silvaro (formerly of NPM) about building a better NPM. Had forgotten about it till now. I’m guessing it went nowhere as that talk was circa 2018-2019’ish
So what would stop a malicious actor from creating a script that infinitely publishes new everything * packages under different users/IPs… did NPM actually just ignore the issue entirely…
Brother, I can see you reading from the prompt
just taking attendance here, Happy Weekend 🎉
here
The comment about JS Devs not being reasonable is certainly on point (It's still a very capable language in the right hands). It is quite scary to see the comments from some of these people. I just hope that they aren't behind critical infrastructure of any sort because I can guarantee it is not "battle" tested. These two devs battle-tested NPM in a way that the NPM maintainers themselves neglected to do. I purposefully do stuff on our infra like this to see if it breaks things and our infra covers broadband connections to payment acquiring and remittance. Its how you make sure bad things like this cannot happen in the future...
Ya, JavaScript is fine, once you get past the oddities and weird behavior. You're then left with a relatively slow interpreted language and a brittle ecosystem. Been doing node for the past 5 years and now I'm dipping my toes into learning golang.
@@joelv4495 Totally agree on the ecosystem, I think it is akin to a lake/pond that has just frozen over, you never know when you're going to fall in.
I enjoy JavaScript, mostly on Deno at the moment in production, however, trying out some production stuff with Bun on a custom Bun Edge Infra (built in-house) to see how it fairs.
I have several languages under my belt from PHP, JS, Go, Python, Zig, Rust, and a few others, but I always tend to float to JS for some reason for most things... Weird I know ;-)
@@joelv4495 Relative to what interpreter language? Mainstream JavaScript engines are pretty fast.
Some companies pay lots of money for people to try and break software. NPM dev's should be happy about this.. :) They just need to fix it.
Also not been able to unpublish, not 100% sure what hardship this causes, especially if NPM can fix the issue in the future.
"Some companies pay lots of money for people to try and break software." the catch is that companies who hire people to break their system give explicit permission for them to try to break things. NPM hasn't hired those people and therefore their actions are considered malicious - do you really think it is okay to break someone else's system without permission? It doesn't matter what intentions they had because the damage has already been done.
"They just need to fix it." wow, how insightful.
"hasn't hired those people and **therefore** their actions are considered malicious"
Really? That black and white, eh?
Unless you're paid by the org, everything you do that disrupts a system is malicious?? Malice? You should look that up. Sometimes accidents happen.
@@MMMMMMarcoif you systems breaks by a few dudes doing random shit it’s is malicious. It’s just a bad system 😉
@@MMMMMMarco I create software, probably like yourself, I have customers who break things because they did things we didn't expect. You know what I don't do, blame the customer.
@@libradrag0n Malicious meaning -> characterized by malice; intending or intended to do harm. Looks like you didn't even watch the video..
I love that people were complaining about the very thing they wanted to be removed yet were still so adamantly against them. They are doing some crazy mental gymnastics.
These kids have stacked a not before amount of bricks on top of each other. They couldn't have known their tower could fall over. Shame on the city for not forbidding it
"Thanks for the explanation, trash!" is got to be one of the best out of context sentences in the existence of this universe!
Lol. I would have never told the NPM or anyone. I would have taken this comedy to dark comedy where the NPM maintainers or developers have to struggle to find WTF just happened on their own.
Every dev should be free to unpublish anything that is theirs - those policies are just plain stupid, I don't know why someone thought it was a good idea. Because of left-pad drama? Well, blame NPM for stealing (yes, that's what it was) kik package from Azer Koçulu to give it to some arbitrary company without any reason or (depending on your views) blame Azer Koçulu for his actions - that is also fine.
Public repositories like NPM depend (nomen est omen) on trust, but the trust should be given from dev trying to use some library to the library maintainers - you can be disappointed by library developers for something in the future, but that's life, your trust issues shouldn't be the reason to take away every publisher their right to unpublish what they've created - that's their basic right.
"The power to destroy a thing is the absolute control over it." ~Frank Herbert, Dune
A package depending on everything seems like an edge case that should be accounted for, it's not even that high up in the insane stuff that some people make.
Hey Theo, could you put trash links on the video description. Just so it’s easy for people who want to follow him as well
Good catch, done!
those devs are awesome who tried to everything
_knowingly_ stress testing someone else's API is not a good idea?
When you started talking about package A and package B...the coin dropped and I was like OH GOD NOT LIKE THIS NOT LIKE THIS
So if I want to cache everything in my privately hosted npn repo by running npm install everything 🤔
All this makes me realise is that we need something that fills a similar role to what Bun does with Node...
Something new that forces NPM to stop lounging and start doing better if it wants to retain its market share
thanks, this is really genius QA project, tanks for telling, it's really important
People upset about the everything package depending on every package, but not upset about the fact that it can do it so easily is bizarre
I really would like to see how a bunch of developers make use of the same strategy or repo of "everything" npm package to publish hundred of packages cloning what "everything" package does so npm have it very hard to remove all the packages using this strategy.
This way, the community could force npm to fix this annoying issue.
I wonder how well pypi, nuget, crates etc would handle such cases.
ok. so they managed to become the node package manager company while not thinking about removing package-references. well done. nothing more to say.
Couldn’t they just have some logic that if a dependency version is “*” then you can unpublish as long as you leave at least one version of the package published?
I agree it's entirely reasonable to do this. But if you were *_really_* trying hard to not be bad against npm or it's users you'd test it in the small.
Make "everything" into "some of the things" and test what broke for those packages. If this was done, no issues were discovered, then you've truly done all you can.
Of course I don't care if they were malicious or not. npm shouldn't be failing against a DOS attack like this and they should certainly fix it when it appears.
They would've not had such ruckus happened if it only was "some of the things", because ruckus itself was caused specifically as it touched "everything"
Main issue was cyclic dependency of "everything" packages on themselves, completely preventing unpublishing very instant they went public, without chance to turn back.
I like the point about this being a giant QA test. It’s what NPM should consider it, and fix the damn bug in their policy. The whole thing is hilarious though!
Thank you for providing a good callout of examples of bad and hostile feedback.
Let’s just address the elephant in the room. Kinda unrelated, but I’ve always said this and will continue to say it - SemVer is inherently flawed.
But to address the package name issue, just make package names alias. When you install a package by a name, it just resolves to a UUID.
Example for Next JS:
“next:550e8400-e29b-…”: “14.0.4”,
Okay, maybe a stupid question but I ask it anyway: Why unpublishing Packages anyway?
If you use an older version of a software you know there are security flaws and issues come along with that over time.
So from my perspective you have to upgrade to the newer version in the long run anyway. You can’t expect that your version 0.0.3 stays forever there.
New versions always make changes necessary not just on NPM but in the whole dev world. And when newer versions break your stuff then you as a dev need to find a way around it or look for a other dependency that fits better or program it for yourself so you don’t need to rely on the daily mood of others. Especially when it’s critical parts of your software: Do you want others to determine what runs inside there? I don’t think so.
And I’m not an NPM dev but what does the star mean? “Get me that package no matter which version is available” for an outsider it seems counter intuitive that this would not just lock the latest version, when the other repo doesn’t care about the version anyway.
And I don’t get the complaints of the commentary about storage, oh really it needs a couple MB of storage is THAT their legit complaint? Also that one of that “mirrors blow up” that person NEVER managed a repo mirror right? Because if you do (what I did for an apt repo) then you expect it to be plenty of storage been utilized for that and you pack some reserve on top of it. So my counter question would be: What’s their planning for their mirrors about?
GitHub issues: 10% proper use, 90% dev is having a hard time with reality and needs to adjust
This made my week, really funny. Damn, 2M packages.... Darn Left Pad, why do people not know what they are using. Happy to say, we don't do any server side JS. Keep JS for the client side only !!!
The fact that there are devs creating issues and blaming these guys for trying out stuff, and at the same time not blaming NPM for their inability to adequately handle their own platform just shows how stupid some people really are
For computer exploits the blame rests on the people who made the software not the exploiter. That should be common sense
It seems to me that the best way to remove the * dependency issue would be to make it so that package can be removed if no packages depend on that specific version AND any packages which depend on any version of it have a different version available to satisfy the dependency.
A little ironic, but it’s almost like the package created a version of npm itself.
I don't blame the package makers to be a little mad for a moment, I probably would have censored their usernames. Patrick did the best he could but still it put folks in an awkward position and I can imagine how frustrating it was, I think publishers just needed somewhere to vent.
I agree with the conclusion though, these folks aren't malicious or bad actors, give them a slap on the wrist sure, but the real answer is to refine the system.
Pretty good filter for finding devs who fail to discern the difference between a personal fault and a system fault.
"Unpublish" is just a convenient feature. It's optional and not necessary in such registries. Anything that was published should stay there.
No, all complaints about not ability to unpublish published packages are ridiculous
Honestly, I'm not surprised that the tweet at 18:20 is from Myles Borins, the guy for whatever reason is super good at letting his personal opinions cloud his judgment on what's best for the ecosystem and npm tools. Literally the reason why npm can't be used with monorepo git dependencies.
"Their only crime was curiosity" - Hackers (1995)
This is the funniest stuff I have seen this week. Thanks for an in-depth report on this!
I was thinking that it was your mic's feat but later when you include other ppl's voice recordings in the videos, I found that the sound seems so similar that with a very naturally high dynamic. Did you go passed an audio enhancement filter for your videos? could you lower the setting or remove it? it is kind of hurting me while listening, reguardless of the volume I set.
You'd think NPM's parent, Microsoft, would encourage a corporate sense of humor after making the Zune. But alas, no..... Brilliantly told, Theo. You are a "developer dramaticus". :D
Does this whole star thing work for any version range? So i.e. a 4.* dependent would prevent me from unpublishing any v4-subversion?
To think that any version range can be unpublish-locked is horrifying!🥴
16:16 lol, they are kinda responsible.
Pushing these systems to the limit is just good QA.
Is that Arc browser you're using to show the images? If so, good choice 💪
You have a package that left pads strings... we don't need to laugh at JS developers because of a NPM issue.
what's really funny is, this is like the 3rd time this specific thing has happened, breaking unpublish
All I 've taken from this is:
- propose npm install everything to every developer I know
- I wonder what's any possible similar loopholes in maven/nuget
- if anyone sane considers this "drama" or "things going to shit", you guys *really* need to start playing classic WoW and frequent reddit more. All of the above is one of the more civil discourses I 've seen on the internet.... ever.
“Oh” is not a number, it’s a letter. Love your stuff.
15:27 This reads like a Persona 5 calling card and I love it
Why are so many in the comments supposing intent on the part of the everything devs? Don't you watch the video before commenting?
It says they invented the idea before the current unpublish policy was in place. So no, they couldn't have known! 😂
least dependent frontend library
"*" Should just be an alias for latest. I can't see any reason for a project to depend on multiple versions of the same package.
I genuinely thought "*" means "latest" in npm, ngl.
Thus imo "*" should always use the latest, even if the latest has been unpublished.
thus 1.0.1 (unpublish) will no longer used and
1.0.0 will instead be used instead
npm maintainers response is so lame and sad to read. I hope they do better, indeed. A system should NOT be "abusable", period. The work trash and Patrick did is great and allowed to discover a flaw in the system. This should be applauded, not criticized like those angry people did because they suddenly couldn't unpublish their package. Damn, people really get angry at the wrong persons in the heat of the moment. We all need to take a step back and realize people who find "exploits" like this are the people who allow to make things evolve in the right direction.
"A system should NOT be "abusable"" that's one of the stupidest things I've heard in a while. Do you even realize that it's almost impossible to do that? Exploits get found every day, that expectation is so unrealistic, it's clear you don't have any knowledge about how these systems work.
i honestly think the respond you get from npm is merely damage-control/what their lawyers advised them to do. They'll probably change something in the following weeks.
If a package depends on * (any version) then it should only prevent you from unpublishing all versions so that at least one version remains.
This video is way too short to justify all the chapter breaks.
The dangers of those negative comments cones from the fact that try to let perfect become the enemy of good enough. JS Devs are aware that NPM relies more in social contract than actual rules so we realize things like this can happen. When they do we learn as a community and find a better paradigm.
What these guys did was show all of us a vulnerability (albiet in a reckless manner) and we should move to fix it, not cast blame on the users who discovered the bug.
Id sure take NPM over the non existent package managers for C or C++.
4:50 Funny, if this dispute happened in France, the name would have not been contentious because the law states that as long as no one could reasonably mistake the package for the app, then they can have the same name.
Npm should treat the star version check as an any. Make it so that you can remove versions of a package as long as it isn’t explicitly depended on and there is another version that exists
In my opinion star should just make it impossible to remove the last standing version of a package, or in general dependencies that can mark multiple versions should make it so all except one can be unpublished, so that the dependency can still resolve. Because star is satisfied by any version so any remaining version would be fine
As someone who's been developing software with JavaScript since 1999, this makes me laugh and cry at the same time.
Also, given NPM's response, this makes me wanna flood the registry with packages that expose this issue in particular... hmmm... if only I had the time...
This is horrifying I had no clue about the * issue and I must be in the minority bc since this came out I've been in agreement with Theo. Like wth are these people thinking piling onto a harmless funny project like this and the response by Patrick was great. Im flabbergasted.
So the solution seems to just keep breaking NPM until they decide to fix this issue, you can't blame two meme-coders. Yeah it was stupid but if the 'vulnerability' still exists it would be trivial to ruin xmas 2024 for everyone at NPM.
In my opinion, if someone can publish their own code, they should be able to unpublish it, specifically to allow situations like leftpad. Azer removed all his code from npm in protest because they ignored that he'd had his kik package up for far longer than the company had existed, and called it a violation of their trademark, when no legal expert would ever support that. Mass unpublishing in protest should be something devs are allowed to do, even if it causes massive issues like leftpad, because those massive issues bring attention to the things people are protesting.
Love all the new stuff you tried. ❤
Fantastic story telling too!
@3:00 "Meme driven development is real" 🤣