by jguimont on 2/22/18, 5:18 AM with 225 comments
by zaarn on 2/22/18, 12:59 PM
Looks like the line responsible checks if the npm binary is run as sudo and then uses the UID and GID of the invoking user when chowning the directory. [ https://github.com/npm/npm/blob/latest/lib/utils/correct-mkd... ]
I feel like screaming, who thought this was a good idea? If I invoke something as sudo, why does anyone think it should try to detect that and do anything about it? I want to run as the user sudo has set, not my own user, OBVIOUSLY.
Don't try to be smart about sudo, you will break stuff.
by lucideer on 2/22/18, 1:21 PM
The idea that correctMkdir() exists at all seems to me to be so wrong-headed.
This comment from the source says a lot:
// annoying humans and their expectations!
Good UX is an important, oft-overlooked consideration, but there is definitely such a thing as taking it too far. If your humans are expecting this level of hand-holding, it's because you've trained them to expect it by pandering to them up until now. This is the kind of problem that should be handled with good, detailed, error message display when users don't get the result they expect, not "fixing" it with over-reaching magic.I'm not sure I'd trust anything put out by the npm team in general from hereonin if they genuinely thought creating the correct-mkdir.js file in the first place was a reasonable idea. Is it? Genuinely open to a counter-argument.
by btown on 2/22/18, 1:28 PM
I had an inkling that NPM was cancer, but not like this.
Yarn, by contrast, has everything you would expect of a Facebook-engineered library: https://github.com/yarnpkg/yarn/tree/master/__tests__/util
Will be closely evaluating a switch to Yarn for our live apps. This is simply sad.
by officialchicken on 2/22/18, 7:58 PM
Since I 'vote' with my code - this migration page has been helpful today - and I hope it will help others: https://yarnpkg.com/lang/en/docs/migrating-from-npm/
It took me ~5 mins to migrate all of my code from npm to yarn. But I don't have complex CI tasks either.
I use ncu to check updates every couple of days, sometimes more frequently. To further distance myself from npm, can anyone comment on the pros/cons of github repo paths instead of package names in package.json?
[0] https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos
[1] https://github.com/npm/registry/issues/255
*edit: formatting
by jlgaddis on 2/22/18, 4:03 PM
> This destroyed 3 production server after a single deploy!
I do think that the developers have a duty to do some testing of their software before putting out releases/updates. However, users also have a duty to perform sufficient testing before they push new versions to their production environments.
In my opinion, it's kinda like losing data because you didn't make and/or test your backups. It's a really crappy way to have to learn a lesson but at least they've finally learned it -- and if they haven't, well, then maybe they will the next time it happens.
by boffinism on 2/22/18, 3:58 PM
Has this issue provoked so much outrage that GitHub can't handle the constant stream of angry emojis on the issue comment thread?
by foepys on 2/22/18, 4:01 PM
Everything is super dangerous as root, one should avoid using root at all costs until there is no other way.
by master-litty on 2/22/18, 6:54 PM
Thankfully, it only affected users running `npm@next`, which is part of our staggered release system
#STOPUSINGPRERELEASEWITHSUDO
Really now? #ANGRYORANGEWEBSITE #PEOPLEGOTMAD
:)by mkj on 2/22/18, 1:30 PM
by hysan on 2/22/18, 3:49 PM
by nwhatt on 2/22/18, 6:29 PM
by akras14 on 2/22/18, 5:59 PM
by InclinedPlane on 2/22/18, 7:53 PM
"Thankfully, it only affected users running npm@next, which is part of our staggered release system, which we use to prevent issues like this from going out into the wider world before we can catch them. Users on latest would have never seen this!"
If you are updating to the latest pre-release of something within mere hours of it dropping and you are updating production systems (presumably that have some business value) with no previous testing then the consequences of that aren't on the devs they are 100% on you. And you don't deserve to call yourself an IT (or Ops or DevOps or what-have-you) professional, that is amateurish behavior in the extreme.
by RX14 on 2/22/18, 5:09 PM
I wrote about this in longer form here: https://github.com/crystal-lang/crystal/pull/3328#issuecomme....
by ishanjain28 on 2/22/18, 2:56 PM
by dictum on 2/22/18, 2:35 PM
http://appleinsider.com/articles/09/10/12/snow_leopard_guest...
(Yeah, it's that much-vaunted Snow Leopard.)
I do remember scrambling to recover my backups. Back then, I didn't make full-disk backups, so I had to assemble my user folder from various places. Everything else that transpired that night and the day after remains a haze.
by jehlakj on 2/22/18, 5:00 PM
by obw on 2/22/18, 12:06 PM
by dlandis on 2/22/18, 6:43 PM
by whatever_dude on 2/22/18, 8:30 PM
With something that has as many people using it, it's just... I dunno, it's disheartening.
Edit: oh well, this was a @next release only. Not as bad. Still scary.
by homulilly on 2/22/18, 7:25 PM
by coreycoto on 2/22/18, 5:57 PM
That is a recipe for disaster.
by erulabs on 2/23/18, 11:08 AM
"Contain async insanity so that the dark pony lord doesn't eat souls"
Just... What. I feel like when you need to reach for tools to "contain insanity", you might want to backup and ask someone who has written to a filesystem before... The linked blog about "preventing the release of Zalgo" and the linked https://blog.ometer.com/2011/07/24/callbacks-synchronous-and... seem completely erroneous. The entire point of callbacks is to _surrender_ control to a function - here is a piece of code to run when you are ready - now, sometime, or never, or maybe many times, as you see fit. Waiting until the next process tick seems so completely unnecessary... This strikes me heavily as "a solution in desperate search of a problem" - although I have that feeling with a _lot_ of NodeJS code I read...
The author of the blog linked on the dezalgo project seems to, at the end of the post, imply the purpose is for performance? By deferring work until a later date?
"The basic point here is that “async” is not some magic mustard you smear all over your API to make it fast. Asynchronous APIs do not go faster. They go slower. However, they prevent other parts of the program from having to wait for them, so overall program performance can be improved."
Other parts of the program _other than the work we've asked it to do_? What if we're only "correctly making" one directory? So we intentionally make our code slower... So that "other code" can run? He continues:
"This makes the API a bit trickier to use, because the caller has to know to detect the error state. If it’s very rare, then there’s a chance that they might get surprised in production the first time it fails. This is a communication problem, like most API design concerns, but if performance is critical, it may be worth the hit to avoid artificial deferrals in the common cases."
So it's slower -and- more complicated, and we're gonna hide it behind a meme. Gotcha.
by _Chief on 2/22/18, 6:01 PM
by ashtonian on 2/22/18, 8:02 PM
by x2e2l2a on 2/23/18, 7:51 PM
by kuon on 2/22/18, 7:00 PM
by Sujan on 2/22/18, 5:58 PM
If you are reading this: You are doing great work, I wish you the energy and strength to ignore the trolls.
by tuananh on 2/23/18, 1:18 AM
- we are relying on 2 people team for our applications. - maintainer doesn't seem to care much about this horrific bug: https://imgur.com/a/v4Ndb
by johnvega on 2/22/18, 9:31 PM
by jxkcicickgkicu on 2/22/18, 5:36 PM
by Sujan on 2/22/18, 5:57 PM
by my_ghola on 2/22/18, 8:27 PM
by atilkan on 3/4/18, 6:17 PM
by digi_owl on 2/22/18, 5:30 PM