1. 11
  1.  

  2. 6

    What am I looking at?

      1. 3

        We don’t discuss all of our security processes and technologies in specific detail for what should be obvious reasons

        isn’t that worrisome?

        1. 5

          When it’s related to spam mitigation it’s not unusual.

        2. 2

          That’s a little worrisome. They built an auto nuker, but didn’t think about what next? Whether it’s a false positive or not, “what if it’s republished?” should be part of the checklist. What if it really were malicious? I just keep retrying until I find a version that sticks.

        3. 4

          The left-pad thing happened again.

          1. 2

            Somebody left padded the safeguards meant to prevent left padding? “no, no, we totally fixed it by adding a ‘are you sure you want to fuck everybody?’ confirmation to the delete command.”

            1. 1

              Has anyone written up the impact this time around?

          2. 3

            It always bothers me when people just complain, loudly, when things like this happen. Shouldn’t developers of all people be sympathetic to a bug getting through and wreaking havoc? It probably wasn’t anyone’s fault and npm was probably working on it super hard so I just don’t see the point of being so negative. Like, being able to install JavaScript just isn’t that important, so just shut up and let them fix it, you know? #hugops

            1. 13

              Shouldn’t developers try to learn from mistakes and design systems that are more resilient? Or anti-fragile if I understand the term correctly.

              There was a thread about npm not that long ago comparing OpenBSD ports tree (or Debian apt, if that’s your poison) to npm, and left pad came up, and the response was “that’ll never happen again.” Here we are, it happened again, but somehow OpenBSD and Debian have maintained their disaster free records. Were they just lucky? Or is it possible there’s something about their design that reduces risk? Is there anything we can learn besides “shit happens, better luck next time”?

              1. 3

                Debian’s package set is intended to work together. There are policies and maintainers and tools. Things like npm are more like a big heap of unvetted, unmaintained (except by upstream), packages that can change or disappear at any time

                1. 3

                  What I am categorically not saying is “don’t criticize npm” (or anyone who has an outage). All I’m saying is that during the actual incident people shouldn’t berate ops teams since at best that does nothing and at worst adds to presumably already very high stress levels which may even impede progress towards restoring services. I’m not really sure that I have a super well-defined gripe other than “don’t you think they already know, duh??”

                  Hope that clarifies what I meant since for whatever reason talking about this outage seems to make me phrase things in the most misleading possible way :P

                  1. 2

                    Ah, gotcha. Funny enough, I just watched the James Mickens talk where he uses the frenemy as a service monitoring service. Tell all your high school classmates about your cool startup to make them jealous, then they’ll always be the first to text you when something doesn’t work.

                  2. 0

                    I believe this issue doesn’t have the same culprit as left-pad, but we’ll see what the npm team is going to figure out.

                    Also, IIRC npm is running a much bigger operation than Debian/OpenBSD packages, so I wouldn’t try to compare them. npm has just way bigger chance to screw something and make many more people upset just because of how much bigger they are than OpenBSD or Debian.

                    1. 2

                      So scale may have something to do with it. How large should a package manager be? One answer is infinite, but I’m not convinced that’s the case. If the answer is finite, what is it? Is there an upper bound on packages in a reliable ecosystem? Should we cap package managers at that number? Why or why not?

                  3. 4

                    How many times do you go back to the same restaurant after getting food poisoning? I realize these people might be good intentioned but at some point it’s time to cut your losses and find a better place to patronize. With better standards.

                  4. 2

                    man, sometimes I just feel like wanting to write a much-used npm package, just so that I can delete it and cause chaos. As a non-js dev, and a minimal user JavaScript in general, seeming this always gives me Schadenfreude.

                    1. 1

                      After left-pad it’s not possible to just remove a popular package, such request needs to go through the support first.

                      https://docs.npmjs.com/cli/unpublish

                      1. 4

                        I don’t understand why it’s possible to delete it in the first place. If you release a piece of code with a permissive enough license you’re accepting the fact that others can keep using that code forever and without any further permission from you. The worst you can do is to stop improving that code. So, why doesn’t npm exercise its right to keep using that piece of code?

                        1. 3

                          This is the stance on Rust’s crates.io:

                          Take care when publishing a crate, because a publish is permanent. The version can never be overwritten, and the code cannot be deleted.

                          I’m sure crates/cargo will encounter its own issues over time but it’s nice that this at least shouldn’t be one of them.

                        2. 4
                          1. write a package and spice it up with non-free and/or patent-encumbered code without license
                          2. publish on npm
                          3. wait (or help it) ’till your package becomes similarly important to left-pad
                          4. tip off / file a DMCA / etc. with npm
                          5. ???
                          6. Profit!1