50 ms·

What NPM should do to stop a new colors attack

• yepthatsreality 5y ago
  Or package signing would help. Something NPM has continuously refused to implement because they believe it is difficult…
  • xeromal 5y ago
    Maybe I misunderstand what package signing is, but the actual owner of the code published the BS. He owns the keys to signing the packages as well.
  • Tajnymag 5y ago
    How would that help if these changes were pushed directly by the original creator himself? Not only form his account but himself as a person.
• freeqaz 5y ago
  This was posted yesterday on HN btw (at least the announcement of this problem). https://news.ycombinator.com/item?id=29863672 https://news.ycombinator.com/item?id=29863672
  • kardianos 5y ago
    rsc's post isn't (directly) about this colors package. It is marginally about npm and broadly about package managers. rsc is stating: (paraphrasing) the current state of affairs in many package managers is not a good design. This is (yet another) reason why package managers should work differently then they often do by default.
• hn_throwaway_99 5y ago
  One feature I've wanted for some time now is the ability to say "give me all the latest versions that are at least N days old" when you run npm install without a lockfile or npm update. The idea being "I want the latest version, but not the absolute bleeding edge, I want something that has at least baked for a bit".
  • umvi 5y ago
    How do you tell your "baked" version is any good though? Doesn't that mean N days after colors.js ground zero you'll start picking up the bad colors.js since it's now baked for N days?
    • zwily 5y ago
      Yes, but presumably it would have been discovered by then.
    • hn_throwaway_99 5y ago
      The "bad" colors.js existed for less than 24 hours before it was removed by NPM. Similarly the other recent malicious packages were detected and removed quickly. The idea is that for maliciously published packages like this (both deliberately in this case, and also when the maintainer's account is hacked) that not all packages that depend on this dependency will need the same length of N. Some users will want to pick it up right away, but some very conservative applications may want N to be much longer. It's basically the idea that alpha/beta users can be the canaries, but those who don't want to take any risk can hold back. Right now, unless you've got a lock file, essentially everyone is pulling the latest released version whether they want to be conservative or not.
      • umvi 5y ago
        Ah, that was the piece I was missing. Basically we are relying on NPM to curate/remove obvious bad packages from the global registry within some timeframe (say, 3 days) and by lagging behind by 3 days you'll never pick up an obvious bad package.
  • xconverge 5y ago
    Seems like you would also want "and there isnt a release 2 days after it" fixing a regression. Starts to get tough :/
• clock99 5y ago
  • IiydAbITMvJkqKf 5y ago
    Oh, you can, just don't be surprised if the remaining community works around your sabotage.
    • clock99 5y ago
• zegl 5y ago
  I was trying to find Marak's motives for this, but I couldn't find much, does anyone know more? On his Twitter Marak is claiming [1] that GitHub/NPM have suspended his account, which is an interesting move, but I guessing that that's the only tool available to prevent further "sabotage". [1] https://twitter.com/marak/status/1479200803948830724 https://twitter.com/marak/status/1479200803948830724
  • okl 5y ago
    Well fuck them. It's his code, he should be able to do with it whatever he wants.
    • smt88 5y ago
      If a major FOSS Linux distro decided to add a virus to their latest release, would you say the same thing? It certainly isn't "his code" anyway. Many people contributed to it with the good-faith belief that he would not use it as a Trojan horse.
      • okl 5y ago
        Using someone's code (for free) doesn't mean you can dictate terms to them.
        • simlevesque 5y ago
          Could you please tell me how to avoid ever using your code ?
        • starwind 5y ago
          If I voluntarily share my lunch with someone at work, I can't poison it even though they got free food. Even if someone at work is stealing my lunch, I can't poison it. We have a right to basic safety even in situations we aren't paying for things. That extends to the digital world. You can't put malware in your open-source project without a giant disclaimer "THIS IS MALWARE. USE ONLY FOR RESEARCH PURPOSES" or something like that
• smasher164 5y ago
  > Essentially every open source software license points out that the code is made available with no warranty at all. Modern package managers need to be designed to expect and mitigate this risk. It's almost like the package manager's job has become to protect users from their dependencies.
  • smt88 5y ago
    It is very reasonable to ask NPM, owned by mega-giant tech firm Microsoft, to protect users from malicious packages.
  • kardianos 5y ago
    Package managers should not intentionally expose users to new versions without explicit action. Go modules did different then npm, and I argue Go modules did it correctly.
    • pmoleri 5y ago
      Until the opposite happens. Some big security hole is fixed in the dependency, npm gets the fixed version by default while Go is stuck in the tested unsecure version. Or Go mitigates the somehow?
      • jrockway 5y ago
        Go doesn't mitigate that somehow. You get the code that you specify, not the code that someone else has decided is better. In practice, for both npm and Go dependencies, you'll get a Dependabot PR that upgrades the dependency for you. Obviously that is Github-specific, so if you're on a different platform, you'll have to subscribe to security updates in some other way. I am guessing there are many services that you can subscribe to that do the same thing.
      • bhedgeoser 5y ago
        Some big security hole is introduced in one of thousands of dependencies, npm gets the insecure version on next npm install while Go is stuck in the tested secure version. How difficult is that to see? I'm not the one to believe in conspiracy theories but this is just nuts.
• btgeekboy 5y ago
  NPM makes an interesting trade off - with the current scheme, security updates which improve the security posture of the application are accepted by default. Those are far more common than malicious updates. Would pinning dependencies lead to larger problems? Imagine if a log4j-like issue showed up tomorrow; most NPM-managed software would just require reinstallation to be fixed.
  • ddlsmurf 5y ago
    The way you do it is simple. Take ruby gems. In development you update as often as possible. When you see the lock file changed, you check you're happy with the upgrades and commit the lock file. When you don't want to keep the newer version, you change the gemfile (package.json) to point to a version you're happy with, ideally with a comment describing why you're pinning, and what you'd have to do to adopt the newer version. In CI/CD you exclusively use the lock file. This workflow is very difficult to emulate with npm/yarn.
    • loo 5y ago
      The gap in this workflow is you have to go out of your way to get a diff. Never mind a diff of what's actually in the .gem. Glancing at changelogs on GitHub only reviews changes from good actors. In practice most of us just update, often with live reload running, and move on. We need mandatory peer review of updates before they're distributed in the first place.
    • spoiler 5y ago
      Can you describe why this workflow is difficult? I'm probably missing or misunderstanding something, as we literally use this workflow at work, and we never had dependency issues with our npm projects... Edit: npm has lock files and a way to install from the lock file (simples way being `npm ci`)
      • ddlsmurf 5y ago
        npm ci is relatively new, before that it was hard to get it to precisely respect the lock file. There is also an issue if your devs don't all decide to use either yarn or npm with the separate lockfiles.
• reidjs 5y ago
  Does anyone have a cli command to check down the dependency tree for these packages? I'm seeing this issue on my company's app and trying to figure out which package(s) it stems from.
  • andrewmcwatters 5y ago
    https://news.ycombinator.com/item?id=29868165 https://news.ycombinator.com/item?id=29868165
• awinter-py 5y ago
  uhhh yes staying pinned to an old version forever solves some problems, but not other problems? article doesn't mention 'npm audit' and how there are cases where you want to encourage an upgrade real long-term solve here is a code review community for widely-used public packages I suspect? am not a huge blockchain fan but this is one thing that blockchain could conceivably do well, because reviews are public, need to be authenticated, exist as compact metadata that can fit on chain, and benefit from public reputation dynamics
  • philosopher1234 5y ago
    Where did you get forever? The idea in the article is to upgrade dependencies only when the maintainers are ready to/explicitly say to.
    • deleted 5y ago
      [deleted]
      • deleted 5y ago
        [deleted]
  • howdydoo 5y ago
    A blockchain isn't needed for that. Authentication needs "crypto"graphy, but not "crypto"currency. This wouldn't be a complete thread without someone mentioning Rust, so I'll do it. cargo-crev is a nice web-of-trust type code review system for Rust crates. https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev
    • awinter-py 5y ago
      I swear I'm not normally this person but I think if 'web of trust' means a database that is replicated in parts across many different computers and uses cryptographic signing to authenticate messages, you're describing the thing known to the bros and the gen-Zs as a blockchain
• ivanstojic 5y ago
  Does anyone else feel awkward about the use of the word "attack" in this context?
  • bhedgeoser 5y ago
    It isn't an attack. He didn't do anything out of the range of his rights.
    • Supermancho 5y ago
      Attack and rights are not exclusive concepts. I would venture to say that your comment is mostly nonsequitor. It's an indirect attack against the lazy and complacent, at the very least. How dare the developer do that to them?! People hate it when you make more work for them and companies will actively fight back so the outrage is predictable. What's surprising is the lack of support for both user and developer agency. Some have gone so far as to say that users have some sort of ownership over someone else's licensed code they chose to blindly change (apply an update) by right of "community" because they used it when it did what they wanted.
  • rsstack 5y ago
    This isn't like leftpad being deleted: he added an infinite-loop on purpose in a patch release to the package. This is a malicious attack. Only later did he delete packages.
    • salawat 5y ago
      No. It's a change he wanted to make to his code. Code is and has always been art. People have been consuming his code, and not keeping an eye on it to make sure it continues to mesh with their own work.
      • deleted 5y ago
        [deleted]
    • charcircuit 5y ago
• vmception 5y ago
  just pin your code to specific versions, the package manager, build tools and linter can just give warnings and case study examples about why the warnings are relevant
  • teach 5y ago
    And then in five years there's a log4j vuln and you've got to figure out how to upgrade a bunch of (potentially incompatible) versions to get a fix. It's a different approach, with pros and cons. Personally I think the npm model has more downsides than other approaches, but it's not clearly always the wrong approach.
• howdydoo 5y ago
  Summary: The author argues that version bounds should be treated as a maximum rather than a minimum, like Go does. e.g., if the latest version of colors is 1.0.3, and you have dependencies that request 1.0.1 and 1.0.2, you would end up with 1.0.2. The end result being, the exact resolved version will have been tested with at least one of your dependencies. I must admit I like the idea.
  • shagie 5y ago
    This in part has to do with how versions are specified and the standard way that this is done allows minor and point releases to be trusted. https://stackoverflow.com/a/22345808 https://stackoverflow.com/a/22345808 - and especially the comment. You will find a lot of `^1.2.3` in version specifications which means everything from `1.2.3` up to (but not including) `2.0.0` is allowed. Specifying `1.0.1 - 1.0.3` is allowed too and would meet the desired functionality - but that isn't the culture of JavaScript developers. The version range is allowed in other dependency management systems (e.g. Maven - https://www.mojohaus.org/versions-maven-plugin/examples/resolve-ranges.html https://www.mojohaus.org/versions-maven-plugin/examples/reso... ) but rarely do I see it used - most often its pinned to a specific known good version.
    • howdydoo 5y ago
      Let's say you have two dependencies each requesting colors: colors@1.0.1-1.0.3 colors@1.0.1-1.0.4 With npm, you'll end up with 1.0.3 because it satisfies all constraints. OP wants to end up with 1.0.4 if at least one dependency tested with 1.0.4 (and reject 1.0.5). I don't know of a way to do this with npm today.
      • gitgud 5y ago
        You might like the [1] "overrides" field in npm v8.3 although I would recommend using it with caution, changing your dependencies dependencies has unknown consequences... even a patch release can break everything... [1] https://docs.npmjs.com/cli/v8/configuring-npm/package-json#overrides https://docs.npmjs.com/cli/v8/configuring-npm/package-json#o...
• pictur 5y ago
  What exactly is this person's motivation to do this? Interest? What does he want to draw attention to?
  • chaostheory 5y ago
    When you're starting to make homemade bombs, there's a good chance that mental illness is involved https://abc7ny.com/suspicious-package-queens-astoria-fire/6425363 https://abc7ny.com/suspicious-package-queens-astoria-fire/64...
• andrewmcwatters 5y ago
  Easy, make --save-exact default behavior. We don't have stable subresource integrity in Node.js yet, but this would be the next best thing.
• freeqaz 5y ago
  I've used NPM shrinkwrap before back in versions 1-3 of NPM. It's a little confusing that the author of this post calls it "new", so I investigated. Since NPM version ~2 (current is 8), you're allowed to publish a npm-shrinkwrap.json file[0] in your package. That's in contrast to a package-lock.json, which may not be included in a published package. Back when I used shrinkwrap, it was pre-lockfiles and it was trying to accomplish something similar to what lockfiles accomplish today. (Lockfiles were added in v5 [1]) I dug up this old StackOverflow post to verify that the behavior of shrinkwrap hasn't changed[2] since many years ago. That doesn't leave me very hopeful. If package maintainers aren't doing this already, and they've been able to for 6+ years, then it's unlikely they will in the near future. (I'm currently investigating how to deal with bad deps with some Open Source tooling I'm building. Feel free to ping me if you have any thoughts to share) 0: https://docs.npmjs.com/cli/v8/configuring-npm/npm-shrinkwrap-json https://docs.npmjs.com/cli/v8/configuring-npm/npm-shrinkwrap... 1: https://nodejs.dev/learn/the-package-lock-json-file https://nodejs.dev/learn/the-package-lock-json-file 2: https://stackoverflow.com/questions/44258235/what-is-the-difference-between-npm-shrinkwrap-json-and-package-lock-json https://stackoverflow.com/questions/44258235/what-is-the-dif...
  • epmatsw 5y ago
    It's because having an actual shrinkwrap file in a library introduces a huge number of conflicts. If library A has 20 transitive dependencies, and library B has the same 20 transitive dependencies, deduplication based on ranges can leave you with only 20 transitive dependencies. If both libraries have shrinkwrap files in them, you can end up with 40 transitive dependencies, even if those are nominally compatible with each other. When you consider that even with the current behavior projects end up with thousands of transitives, you're looking at adding literally thousands or 10s of thousands of duplicate dependencies to a project. That's not even considering that some duplicate dependencies will just break things if they show up multiple times in a project (older versions of react, for example).
    • freeqaz 5y ago
      Ah, that totally makes sense. I know that's what "peerDependencies" is used for by many projects. For example, `react-dom` has a peerDependency on `react`. This can either be pinned to an exact version (react-dom@1.1.1 must be used with react@1.1.1) or it can require a range (react-dom@1.1.1 may be used with react@^1.0.0 (any version 1.0.0 and up)). That seems tricky with the shrinkwrap, as you describe above, because it might create additional versions everywhere instead of trying to collapse them. (If you have 3 versions of `react` in peerDependencies, but each package had a npm-shrinkwrap.json, then you'd end up with 3 different versions of `react` installed.) Would the burden then fall on your package manager to resolve this, ie npm or yarn? If it sees 3 different shrinkwraps (1.1.1, 1.1.2, 1.1.3) but they all have compatible peerDependencies (>=1.1.1, >=1.1.2, >=1.1.3) it could then pick the version that is compatible with all of the peerDependencies but that also exists in a shrinkwrap (so 1.1.3). That would protect you from this "colors" scenario of somebody publishing `1.1.4` with malicious changes because, unless somebody were to shrinkwrap it, then it wouldn't get picked up by default. (In contrast to the current semver, which likely would pick up 1.1.4 upon a fresh `npm install`). The inverse side of this is highlighted by another comment on this post: That semver makes absorbing security updates an easier process in the event of a log4j-style vulnerability. There is always a tradeoff, for sure!
• ghostly_s 5y ago
  > Other package managers should take note too. Marak has done all of us a huge favor by highlighting the problems most package managers create with their policy of automatic adoption of new dependencies without the opportunity for gradual rollout or any kind of testing whatsoever. (Emphasis added) - is this actually a widespread practice? That's certainly not how apt packages are handled...my impression was this is a problem unique to the js ecosystem.
  • dane-pgp 5y ago
    I don't have an answer to your question, but I'm glad you've highlighted this part of the article. The idea that an attacker "has done all of us a huge favor" by attacking the free software community is so toxic that it needs to be called out, even if it was meant somewhat in jest. If we don't reject this logic, then we'll get more attackers claiming "just a prank, bro!" and "social experiment!", like the University of Minnesota researchers carrying out human experimentation on kernel developers without their consent: https://www.theverge.com/2021/4/30/22410164/linux-kernel-university-of-minnesota-banned-open-source https://www.theverge.com/2021/4/30/22410164/linux-kernel-uni...
    • UnFleshedOne 5y ago
      Well, do you want bad security practices changed because of a prank that hit millions of machines or because of a cryptolocker that did the same? We should encourage old-style prank hacking.
      • dane-pgp 5y ago
        I'm not sure what this prank showed beyond what all the previous malicious NPM packages already showed, other than that developers of free software are unstable and can sometimes ruin your day for lolz. Even if you accept the idea of vandalism being used for a positive purpose, a better form of protest would have been to make the package just print a message saying "This software has been abandoned by its author. Please pin your dependencies to known good versions." and then exit. That would still have been annoying to the people having to do that unnecessary version pinning work, but would at least have preserved some shred of sympathy for the maintainer.
• fold_left 5y ago
  Checking in your dependencies with https://github.com/JamieMason/shrinkpack https://github.com/JamieMason/shrinkpack can help insulate you from these problems until you're ready to face them. I created this before left-pad and thankfully meant that we were unaffected. A lot of developers, understandably, baulk at checking in dependencies, but there is a concrete benefit in being able to continue uninterrupted during outages.
• mfer 5y ago
  Basically, applications should use a lock file for dependencies based on known tested good versions of dependencies. How is it that people aren't doing that today? For the sake of security and stability, lock files should be used.
  • danenania 5y ago
    They are used. A lot of the comments in this thread that are about NPM specifically are strawmen, since it has been standard to use lock files for years. You could still have an issue if you need to update a dependency, for security or other reasons, since it could bring along a bunch of updated sub-dependencies of its own (and sub-sub-dependencies, and so on). But that problem is not unique to NPM and exists in any language or platform that includes package management.
• mrlonglong 5y ago
  Time we had a new FOSS licence that specifically forces commercial users to pay for it. Why should big greedy corps profit from using software that's free?
  • junon 5y ago
    "FOSS" and "forces payment" are conflicting ideals.
  • chaostheory 5y ago
    We already have them. If I'm wrong, then we wouldn't need them. Just change the license for future versions like SugarCRM did. They didn't break anything and now they have paying customers. https://sugarclub.sugarcrm.com/engage/b/sugar-news/posts/sugar-community-edition-open-source-project-ends https://sugarclub.sugarcrm.com/engage/b/sugar-news/posts/sug... You don't need to do something crazy like what Marak did.
• alana314 5y ago
  Maybe the JS language itself should vet and absorb some of these more common libraries. Printing pretty colors in a console could be a feature of the language itself.
  • CottonMcKnight 5y ago
    There is a TC39 proposal for a "Javascript Standard Library." It's at stage 1, which is better than stage 0. https://github.com/tc39/proposal-built-in-modules https://github.com/tc39/proposal-built-in-modules Even so, unlikely that a "Faker" would become part of any such standard library.
    • no_way 5y ago
      There was a major push few years ago, but it died down. Basically performance benefits of built modules weren't worth it and with that standard library proposal also lost momentum.
  • throw_m239339 5y ago
    > Maybe the JS language itself should vet and absorb some of these more common libraries. Printing pretty colors in a console could be a feature of the language itself. Maybe Node.js should start shipping with a substancial standard library instead of making developers rely on NPM. Node.js can't even parse a multi-part request body without a third party library. So much for a HTTP server that doesn't even implement the HTTP spec...
  • o_m 5y ago
    Isn't Deno doing this with its own standard library?
  • pawelmurias 5y ago
    A standard library over time would end up consisting of ancient garbage. You could have a vetted collection of node.js module on npm.
  • soylentgraham 5y ago
    What if my engine doesn't have a pretty console? Javascript isn't just node and web browser scripting. Things like UI should not be in the language.
• dang 5y ago
  Recent and related: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps - https://news.ycombinator.com/item?id=29863672 https://news.ycombinator.com/item?id=29863672 - Jan 2022 (955 comments) Important NPM package colors from Marak causing console problems at the moment - https://news.ycombinator.com/item?id=29861560 https://news.ycombinator.com/item?id=29861560 - Jan 2022 (1 comment) Creator of faker.js pushed an update of colors.js which has an infinite loop - https://news.ycombinator.com/item?id=29855397 https://news.ycombinator.com/item?id=29855397 - Jan 2022 (1 comment) Marak adds infinite loop test to popular colors.js - https://news.ycombinator.com/item?id=29851065 https://news.ycombinator.com/item?id=29851065 - Jan 2022 (7 comments) Marak's GitHub account suspended after he erased his faker project - https://news.ycombinator.com/item?id=29837473 https://news.ycombinator.com/item?id=29837473 - Jan 2022 (53 comments) Faker.js Erased by Author - https://news.ycombinator.com/item?id=29822551 https://news.ycombinator.com/item?id=29822551 - Jan 2022 (2 comments) Popular JavaScript package “Faker” replaced with message about Aaron Schwartz - https://news.ycombinator.com/item?id=29816532 https://news.ycombinator.com/item?id=29816532 - Jan 2022 (3 comments) Faker.js Has Been Deleted - https://news.ycombinator.com/item?id=29806328 https://news.ycombinator.com/item?id=29806328 - Jan 2022 (9 comments)
  • deleted 5y ago
    [deleted]
  • kardianos 5y ago
    This isn't actually about colors repo. It is about package manager design.
• jeffrallen 5y ago
  I cannot fathom why Russ bothered writing this. Npm is a dumpster fire, and below him.
• lmeyerov 5y ago
  It seems npm and GitHub do take action in cases like leftpad and colors.. and people don't like them (Microsoft) doing so unilaterally. Maybe part of the 0-day fix is go multiparty: allow weighted votes by dependents to take over the namespace to force a patch/reversion. You own your code etc, but the OSS distro service has its own community-owned rules, and you are free to run a competing package manager without them. By using community managed package managers, you signal your intent not to break your users & contributors, and give an explicit remediation mechanism for handling such trust chain violations. Instead of a hundred-message GH thread, we get a voted minor version bump same-day. Though agreed with the sentiment of 'prefer stable' during install would be A+. 1am package scans was a cruddy way to start my vacation.
  • omegalulw 5y ago
    > Maybe part of the 0-day fix is go multiparty: allow weighted votes by dependents to take over the namespace to force a patch/reversion. You own your code etc, but the OSS distro service has its own community-owned rules, and you are free to run a competing package manager without them. Not a good idea. You are pretty much asking to be review bomb. You would need very good moderation to be able to trust votes. That means npm spending a bunch of resources on hiring them, not sure if they are up for that (no, free mods aren't the solution).
    • lmeyerov 5y ago
      Yep, so build in adversarial controls like thresholding. The status quo is already beyond what gh/npm are managing: they already need the mods they aren't hiring. Scanners are helping, but a big part of GH is community tools, so weird not to figure it out here too.
      • patmorgan23 5y ago
        Or you could just pin to a specific version and not update until you test.
        • 5y ago
• jacquesc 5y ago
  It's really tricky when you end up using libraries 4 levels deep, and never consciously chose something. Looking at one of our production projects, we use colors via: "css-loader" -> "cssnano" -> "svgo" -> "colors" I wish I could say I spent the hours to go line by line through every dependency of our app. But that wouldnt leave much time for anything else.
  • bhedgeoser 5y ago
    It's the responsibility of "svgo" to make sure it's direct dependencies are alright.
    • notatoad 5y ago
      Sure, that is technically correct and if your only goal is to assign blame that's helpful to point out. But it does nothing to prevent this from happening again. The point here is how we can make it easier for svgo and every other package to avoid the problem in the first place.
      • bhedgeoser 5y ago
        * It should be the responsibility of "svgo" to make sure it's direct dependencies are alright.
        • gopher_space 5y ago
          Why can't you point that attitude in both directions?
    • joe_the_user 5y ago
      Who's paying svgo to do that checking? NOTE: this isn't an open source versus closed source thing. Linux has distributions which test included packages (to varying extents, I'm sure) and some of these are commercial operations. It's not impossible to have code whose verification you have paid for, to one extent or another, even with open source. (and hey, you can install malware with automatically updating closed-source see Solarwinds).
• vorticalbox 5y ago
  Could this have not been avoided by using a fixed version in package.json E.g 5.5.3 rather than ^5.5.3?
  • MaxLeiter 5y ago
    I made a post yesterday where I advocated for this (with lockfiles) at https://maxleiter.com/blog/pin-dependencies https://maxleiter.com/blog/pin-dependencies but it was pointed out to me that pinning dependencies would cause duplicates in your rollup/webpack outputs. YMMV, as I haven't experienced that but haven't extensively looked into it
• shadowgovt 5y ago
  It's worth asking, I think, how much energy should be spent against guarding against an attack like this in the future. I think every organization's risk model is different. In this case, the Net interpreted Marak's actions as damage and seems to have effectively routed around them. There was disruption, but we already have systems in place for flagging broken or malicious versions (`npm audit` being one example). For people willing to have the system work 99% of the time with the occasional Marak-screw, we already have a working solution in what currently exists. For people who cannot tolerate that level of risk, you have to firewall your package sources and only allow use of vetted code dependencies in your software. Open source relies, in the end, on trust. Marak broke trust and that's all. The question isn't "How do we prevent people breaking trust" (that's impossible; humans have free will) but instead "How do we mitigate damage / protect that which cannot be risked if someone chooses to break trust?"
• aardvark179 5y ago
  How about a foundation to run the package repository (for independence), a requirement for multiple sign offs to publish an artefact, and a requirement that successor maintainers exist? Yes, this would create a barrier to entry, but I’m not sure that’s a bad thing.
• GeekyBear 5y ago
  In this case, Microsoft seized ownership of an open source project and modified the code without the permission of the person who still controls those copyright rights that they haven't specifically waived. Legally, shouldn't Microsoft limit themselves to banning the developer from npm and forking their repos under a new name?
  • that_guy_iain 5y ago
    Didn’t they just revert it to a previous version? A version they are legally allowed to distribute? They are legally allowed to ban people and use whatever urls they want to host git repos. They are also legally allowed to give someone else permision to npm publishing under a specific package name. Seems like they did things they are allowed to do.
  • iakov 5y ago
  • profmonocle 5y ago
    Microsoft isn't asserting any sort of ownership - colors.js is licensed under MIT. Microsoft is free to make whatever changes they like and redistribute said changes. (But as was already mentioned, they merely dropped the broken versions and set the last working version as "latest".)
    • GeekyBear 5y ago
      > Microsoft isn't asserting any sort of ownership The person who holds the copyright isn't allowed to access the repo. Microsoft changed the code in their repo. Those things don't happen without Microsoft asserting ownership.
      • monkeybutton 5y ago
        Who owns repo? The author has a right to package code, but he doesn't want have the right to use other people's platforms to distribute it. This is a lot like twitter bans isn't it?
• diogenesjunior 5y ago
  when i have any code that requires dependencies, i always use an exact version. i am mainly a python developer, so my requirements.txt would look like this: flask==1.1.1 request=2.3.2 tensorflow==3.4.2 i tested/built my code with these versions, so i know that these versions work. when i install my dependencies, i use these versions, not the latest version. is there a way to do this with node.js? and wouldn't using this method solve any problems? pardon me if i'm missing something
  • rronalddas 5y ago
    Yeah, it can be done easily using lockfiles, both yarn and npm allow that. You would seldom run npm update directly in production without testing the updated deps first
  • cjpearson 5y ago
    Yes, if you put exact versions in your package.json and do not prefix them with a caret or tilde, npm will install the exact version. A package-lock.json version will also pin your transitive dependencies to a specific version. Unfortunately, the default behavior of npm is to add a caret to the version number which npm interprets as this version or any greater minor/patch release.
  • tln 5y ago
    Yes, you can specify an exact version in package.json. The easiest way is by adding "-E" when installing: npm install chalk -ES yarn add chalk -ES The -S installs and saves to package.json (equiv to requirements.txt). That results in: "dependencies": { "chalk": "5.0.0" } which is an exact dependency. By default npm and yarn use "^5.0.0" which means minor upgrades are allowed (5.x.x).
• mavhc 5y ago
  Is it possible to have users vote on whether a new version is "good"? Maybe automatically via software that depends on the module successfully completing test suites?
• no_wizard 5y ago
  Attack is hyperbole. This wasn't an attack. Nothing was attacked. This verbiage has got to stop being used around this. A maintainer of popular packages got fed up with being a maintainer - rightly or wrongly - and decided that they were going to alter their code - publicy no less (a far more dubious move would have been to make these changes in private and release that to npm, without pushing it to github also, in my mind) - and that means this code was working as intended by the project / package maintainer. It was not injecting harmful code onto the machine, it was not an "attack" on anything, in any real sense. I feel all the media is doing so far is raking the maintainer over a fire, instead of asking the question of how did we get here in the first place? Why would a maintainer feel they need to take actions like this? What are they trying to achieve? Instead of talking about the role of maintainers, consumers, and what to do about the state of open source software and its longevity, we are instead using this moment to go after the maintainer as if they were doing the equivalent of using their npm packages to inject actual malicious, harmful code on the consumer machines, like a cryptominer. I know it inconveniences everyone, sure, and would I have done this if they were my packages? No, I'd go through a normal deprecation process of announcing its deprecation, archiving the repository, and plainly stating that the package is no longer maintained. With that said, consumers can always choose a different library. This wasn't malicious, or an attack. It was an update to the package working as the maintainer of the project intended. If lodash issued a breaking change, would that be considered an "attack"? They even followed semver, by bumping the packages to their next major version. I think this event also served to expose how little organizations have around testing for breaking changes in their dependencies, which may be adding fuel to the issue. EDIT: this is a plea for more nuance in the conversation. I think there has been an unreasonable amount of haste in passing judgement in this situation, that, after doing even just a little bit of background research, seems to suggest there is more moving parts than meets the surface.
  • encoderer 5y ago
    I think you’re being far too kind in your interpretation. If one wishes to stop maintaining, all you must do is nothing. Instead, by pushing an intentionally broken patch, It is foreseeable that there will be hundreds or thousands of maintainers of other code that will have to respond to your actions. I think it’s reasonable to call that an attack.
• thayne 5y ago
  On the flip side, what if a common dependency has a critical vulnerability, and a fix needs to go out quickly? If evey package needs to update dependencies to get the fix, that can add considerable delay to patching all vulnerable systems.
  • dane-pgp 5y ago
    And of course a clever attacker would do this: * add some code with a subtle and accidental-looking vulnerability to a package * wait until lots of other packages were dependent on it * report the vulnerability so the package got flagged by "npm audit" as needing an urgent update * release a new version with a more damaging malicious payload in it, which everyone would rush to install. The way to stop this scheme would be for NPM to make sure that "npm audit fix" installs the earliest non-exploitable version, and to make sure that that version contained only the minimum changes necessary to fix the reported vulnerability. That would mean having engineers whose job it is to do security reviews of patches to packages that have vulnerabilities found in them, but that shouldn't be too much work to take on. I mean, how often are NPM package vulnerabilities found? Two per day, or something?[0] Also it would require that packages are reproducibly built from their published source code, which sadly isn't a thing yet.[1] [0] https://github.com/advisories?query=type%3Areviewed+ecosystem%3Anpm https://github.com/advisories?query=type%3Areviewed+ecosyste... [1] https://hackernoon.com/what-if-we-could-verify-npm-packages-c2a319cff758 https://hackernoon.com/what-if-we-could-verify-npm-packages-...
  • deleted 5y ago
    [deleted]
• holoduke 5y ago
  Nothing. Better live in the world with some gaps than a completely closed prison. Because that's what you get when you start governing stuff like this with an endless list of strict regulations. Better accept that things can go wrong sometimes. It isnt the end of the world.
  • turminal 5y ago
    Have you read the article? It doesn't look like you did.
• greggman3 5y ago
  I know this isn't a solution but .... I wondered if npm should run the tests before it allows a project to be published. In in particular it should run the previous tests. If the current package is 1.2.3 and you upload 1.3.0 the 1.2.3 tests should pass on 1.3.0 or else fail (not sure that's even possible to automate given the current design) Even if work poor or no tests would get around this but hopefully people would chose well tested packages over poorly tested packages.
  • msoad 5y ago
    1. Tests should not be published 2. You can update the test script with the release too: "test": "echo pass"
    • deleted 5y ago
      [deleted]
    • greggman3 5y ago
      > 1. Tests should not be published tests are published, they just are currently used by anyone but the owner > 2. You can update the test script with the release too: "test": "echo pass" which is why my suggestion was for npm to run the previous tests as well as the new tests. Given that people will more likely choose tested packages vs untested a package that just had "echo pass" wouldn't get much traction. And, given my suggestion is that npm run the previous tests, you couldn't just change the tests to "echo pass". Your only opportunity to do that is a major version but major versions are not upgraded automatically in any form so people would be more likely to catch and flag.
      • msoad 5y ago
        I see what you're suggesting. That' clever! Not sure how scalable it is. I'm sure if you ask npm folks they will give you some wild examples of packages doing crazy stuff!
• asiachick 5y ago
  I just want to add, colors is pretty poorly designed package. It modifies the prototype of String! This is a well known anti-pattern (yes, there's a safe mode you can opt into but it shouldn't have the first mode at all) It also has a ridiculous "theme" feature that can be replaced by the same amount of standard JS. Meaning you gain nothing by using the theme feature that you couldn't do yourself except you make your code more dependent and more likely to break/need updating/etc since you added more dependencies to achieve something where none was needed. It does tries to do too much by auto detecting whether or not to emit colors and provides no way to tell it what you actually want (since it's guess may be wrong)
• franciscop 5y ago
  The whole "grab the latest semver compatible version" was designed for a reason, and just pinning to a specific version would bring us to a world where very different articles need to be written. Specifically, when there's a vulnerability in any dependency (a thing that happens much more often than a rogue OSS dev) the upgrade process would be a nightmare for everyone involved. You have to chose one of the two evils; automatic bug/vulnerability fixes, or protection against rogue OSS devs you depend on. I'd say the former is an order of magnitude more common and important, and so the npm/JS world works this way.
  • wbl 5y ago
    Have you used Go? Updating a module is easy and it uses exactly the solution described above.
  • zorr 5y ago
    I wonder if both are possible with a trust system where releases can be approved or signed by community members. This way we can have automatic semver updates for releases approved by people we trust. Something like "I trust NPM so accept all releases that NPM has approved". Large companies could have their own internal approval keys etc.
    • remram 5y ago
      This exists, it's called crev: https://github.com/crev-dev/crev https://github.com/crev-dev/crev It is really good, allowing for distributed reviews, not necessarily from the people authoring your dependencies. The OP suggests that if you -> A -> B, the package manager should only install versions of B vetted by A (or close); I think this doesn't scale well in practice (all the more so if the only way A can vet a new version of B is by doing a new release). Having the possibility to rely on other people to vet releases (possibly in your company) opens a lot of doors, such as the ability to not trust the author of A at all.
    • boris 5y ago
      That's in a sense what Debian is doing with its experimental/unstable/testing/stable repositories. We also adopted a similar approach in build2 where we have queue/testing/stable sections of the repository. A newly submitted package version first lands in the queue where it is not yet visible to anyone. After it has been tested and reviewed, it is migrated to testing where it becomes available for testing by the larger community. After some time, if no issues are found in the package, it is migrated to stable. You as a user of build2 have a choice from which section(s) of the repository you want your dependencies.
• kristianpaul 5y ago
  Should do nothing. If your software come with a contract, well, that's different I guess. Otherwise, make sure you have a reproducible for a start.
• paulhodge 5y ago
  The many suggestions about what NPM should do differently are universally all really unsatisfying, rearrange-the-deck-chairs-on-the-Titanic level solutions. At the end of the day, if you're running code that you didn't write or verify yourself, you're taking on risk. IMO the next hugely successful package manager (in whatever programming language) will be the one with a really good capabilities model, so you can run untrusted code with much less worry.
  • klabb3 5y ago
    Module-level capabilities is an interesting idea. We still don't have process level capabilities though, at least not for native code. Yet another argument for wasm and friends, I guess...
• aaron695 5y ago
• nailer 5y ago
  Was hoping this would be something productive - like giving some help to OSS developers suffering burnout - but it just advocating for not updating to minor versions. Simplistic and will cause other problems.
• gigel82 5y ago
  I take issue with the title of this article. This was not an attack. The project's author committed a change to his own open source project, which he had every right to do. Was that an asshole move, and did he lose all credibility in the OSS community? Yes, absolutely. But it was not an attack. In fact, I also take issue with GitHub / Microsoft taking over the package and am very worried about the precedent that sets, regardless if their motives this time appear to be entirely selfless.
  • spankalee 5y ago
    Just because the package owner had implicit permission to run code on other people's machines, doesn't mean that this wasn't an attack. A postal carrier may have a key to a building to deliver mail, but if they use it to turn on all the faucets and leave the doors open, it's an attack.
    • xvector 5y ago
      It's still his project. He could have deleted it for all I care, it's his every right. I wonder if GitHub/NPM even have the legal rights to modify the code you publish, depending on your license.
      • saghm 5y ago
        I mean, for almost every mainstream open source license, the answer to that is a pretty definitive "yes, they can", right? The most stringent of them require things like attribution and open source the modifications, neither of which seem like requirements that Github/NPM would have any qualms with following.
        • xvector 5y ago
          But does GitHub/NPM have the right to modify his code and publish it under his account/his name? I doubt that is legal.
          • 5y ago
• spankalee 5y ago
  So who has a great Node development environment that runs in a container? One of these days a rogue package is going to try to do serious harm on my computer and I'd like to start figuring out a setup to protect myself.
• hakube 5y ago
  Pin dependencies. That's it. If you want to try out the new version, just test it on staging. Otherwise, you'll just be shooting yourself in the foot
• UnFleshedOne 5y ago
  That justifies using something like rollup or webpack to bundle all your dependencies into one huge file to make a "static build" of sorts. Then you can at least do a cursory check for anything obviously bad in the changes, if tree-shaking works well enough. It leaves vulnerabilities open until next release, but deals with direct attacks.
• thenerdhead 5y ago
  Some ecosystems adopt latest semantic version (i.e. caret/hat versions). Some ecosystems adopt lowest applicable version (i.e. explicit/implicit ranges). Although this may be more specific to the former ecosystems, I think the real lesson here is that there's associated risk with not pinning your dependencies in favor of receiving security/bug fixes. Yes, lock files are a thing, but there's still a real downstream effects to these things when they are regenerated/created. Was the author within their rights to do this? Absolutely. Was the package manager within their rights to mitigate harm? Absolutely. These actions do not go without consequence. Time will tell what those are exactly. This is not the first time this happened, and it won't be the last.
  • remram 5y ago
    Do you have any example of a package manager that adopts the lowest applicable version?
    • shagie 5y ago
      Maven is most frequently done with a pinned version and rules about the order and depth of dependencies. libBar:1.0 libFoo:1.1 libFoo:1.0 In this example, libFoo:1.0 is defined at a higher level than the transitive dependency for libBar which defined libFoo:1.1 -- libFoo:1.0 will be the version used. libBar:1.0 libFoo:1.1 libQux:1.0 libFoo:1.2 Here, libBar is defined earlier in the dependencies. libFoo is used by both libBar and libQux, but since libBar was defined earlier, it has precedence. https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html https://maven.apache.org/guides/introduction/introduction-to... There are ways for the project to specifically redefine versions to be used, exclude certain dependencies, prevent the build if certain versions show up and enforce various rules upon the build. https://maven.apache.org/enforcer/enforcer-rules/index.html https://maven.apache.org/enforcer/enforcer-rules/index.html It is possible to extend the build in rules - https://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html https://maven.apache.org/enforcer/enforcer-api/writing-a-cus...
      • remram 5y ago
• rzwitserloot 5y ago
  This could turn into a real legal test for FOSS licenses! Merchantability seems to be the root issue here. This action by Marak Squires (maintainer of the projects) would ordinarilly be illegal by way of breaking the law on implied merchantability: The 'product' (faker.js and colors.js) that the 'vendor' (Squires) supplies to its customers (users of the package) is intentionally designed to be not at all fit for the purpose that it is 'advertised' as. it's like a bakery selling objects that look exactly like bread, but which aren't edible. Even though the shop does not _call_ any of its products 'bread' - the look of the store and the name of it, as well as its reputation as having been a bakery before, implies it. Calling something 'bread' implies it is edible. The interesting snafu is two-fold: FOSS license, and a more fundamental issue. The FOSS license attempts to disavow an implied right, and does so in a license that does not require acknowledgement of the 'buyer'. A casual analysis would indicate that a FOSS license is therefore laughably unenforcable: Of course you can't do something as fundamental as denying an implied right without clear explicit acknowledgement from the other party, let alone via a license that's buried 5 pages deep into an About... dialog someplace. On the other hand, FOSS is free, so the 'buyer' would presumably be expected to realize extraordinary rules attach to their 'purchase'. Or better yet, perhaps it is better to stop couching this in terms of 'product', 'vendor', and 'buyer'. If you paid nothing, are you a 'buyer'? If this isn't a transaction then you aren't a merchant and therefore merchantability cannot apply. (In this sense, all FOSS licenses mentioning merchantability is in fact __reducing__ the legal protections of FOSS authors! By using that term you're, yourself, construing the relationship between the FOSS author and the FOSS user as a vendor/buyer relationship! But, I'm not a laywer, so I best put this pet legal opinion back in the shed where it probably belongs). At any rate, however FOSS is supposed to imply non-merchantibility (be it the license, or simply that you never paid for it, or some combination thereof): That would, I think, be __required__ for this act to not have been illegal. Once it's illegal, github's actions are entirely justified. If it isn't legal, then github's / npm's actions of taking over the 'project' is more dubious, though I'm pretty sure the github agreement gives them the right to do this. And if you think that github cannot just claim this right via a clickthrough license.... github is __free__. If github can't claim this right via a clickthrough, then Marek's claim that he isn't on the hook for a merchantability promise seems doomed, making it illegal, making github justified yet again. Turn left or turn right, github was allowed to do this. Whether it's 'moral' - oof. That requires beers and a long night I think. I think it's a test of the FOSS license. If a bakery decides to bake their bread intentionally with extremely foul smelling chemicals (harmless, other than that it makes the bread test utterly disgusting), even if they announce it on their facebook page or what not, that's not just unethical, that is illegal: There is an implicit merchantability and all that. It seems to be rather obvious that a software product that implies that it does a certain thing (and whether you go by its name, its description, or simply by the fact that it did that thing before the update, a thing that is well described and that the author is clearly aware of, is making no efforts to correct, and is in fact contributing to by e.g. exposing documentation that echoes this) - and then it intentionally doesn't do that thing, is breaking the same law. However, the FOSS license explicitly denounces this, which you ordinarily cannot do, but backs that up with: Well, ordinarily, you'd be paying something for this, and you're not, so even implied merchantibility. It does this in a worse-than-click-through style license (you do not need to explicitly acknowledge a FOSS license). Ordinarily (and I am not a lawyer), I'd say the license style of FOSS projects is obviously stupid: You can't write an extreme license (and 'disavowing merchantibility certainly is extreme!') and do so in such a roundabout way as a file buried in some about page someplace. However, the rub is: You don't pay for FOSS, and the concept of FOSS itself (including disavowing merchantibility) is somewhat well known. One could make a plausible claim that 'buyers' can be expected to either know what FOSS is, or at least that the literal zero cost surely means it comes with caveats that are extraordinary. Perhaps there's no need for FOSS licenses. If you don't pay anything, can you impose duties? US law (and many other country's laws) do this all the time, but for this specific case: Treating someone who puts a FOSS project online as a 'vendor', who therefore implicitly adopts the duty of providing a merchantable product (which they then attempt to get rid of via the license; for the purposes of this defense, lets assume that FOSS licenses are not legally binding, so it applies) - that's weird, right? The 'buyer' isn't a buyer; they did not pay. I'm in fact tempted to think that FOSS licenses __reduce__ rights; by having that license and mentioning merchantability you've construed your relationship as FOSS author with the FOSS user as one of vendor and buyer. But, I'm not a lawyer, and the OSI and the lot are, so I should probably defer to their judgement, perhaps? Then again, a lawyer is somewhat unlikely to get behind the notion that 'no legal documentation is the best solution here, let common sense dictate and pray instead'. What being lawyers and all, even the good persons.
• dathinab 5y ago
  > The specific misfeature is that when you use NPM to install a package, including a command-line tool, NPM selects the dependency versions according to the requirements listed in package.json I thought in 2021 its well known that not using locked dependencies for npm is a no-go? Just people accidentally braking dependencies happens so often that in my experience not using a lock file is not an option. > a package declares the minimum required version of each dependency, and that’s what the build uses if that is how it works it IMHO sounds like a way worse choice for security. Personally I prefer what cargo (rust) does, if there is no lock file, pick the newest compatible version and create a lock file. If there is a lock file use the version of the lockfile (if possible, i.e. if the semver requirements in the project file are not incompatible with the current lock file). Then it's not a question of weather you use some command to create some freez/lock file or similar, but just weather you commit it. It also means that during local development your version will not magically bump (which would be horrible). Similar you can tell cargo to bump dependencies in the lock file to the newest semver compatible version, or increase the minimal version number in the Cargo.toml file. Similar you can use options to _only_ use dependencies in the lock file failing if it's not compatible with the current project definition. Sure cargo still has a lot of ways it can improve in, but I still prefer it over more or less all alternatives I ever tried (I haven't tried all of them).
• pabs3 5y ago
  A better option would be distributed social code review like crev: https://github.com/crev-dev/ https://github.com/crev-dev/
• yuchi 5y ago
  I know I will be buried in these comments but PLEASE NO. Do NOT pin specific versions in you package.json unless you know you need to. Instead DO USE package dependencies pinning as much as possible: 1. Commit and keep package-lock.json / yarn.lock files 2. Use the right commands in CIs (npm ci / yarn install --frozen-lockfile) 3. Teach others
• aoetalks 5y ago
  >The right path forward for NPM and package managers like it is to stop preferring the latest possible version of all dependencies when installing a new package As a package author specifically around one that wraps/interacts with REST APIs, begging people to upgrade at my company so I can deprecate old APIs can be a challenge. Maybe that's an argument for a monorepo, but still.. Obviously the current system has its flaws, but nudging packages towards newer code does have other clear benefits, like them automatically getting security fixes.
• option_greek 5y ago
  There should be a reputation score for new releases on npm with scores from beta users who are part of the community. Sounds similar to app store but more community controlled. In general, there should be a risk assessment score on npm for each package sourced automatically from different criteria like how many maintainers are there in a project, ownership changes etc. Also, making the new package available only to few % of random users would have limited the impact. Overall this pull with complete trust is just asking for trouble. And yeah, this developer needs to be committed to a facility for his own good (if this doesn't qualify him for that then I don't know what will).
  • toastal 5y ago
    That's literally gatekeeping. It took me so long to get enough karma on HN to be able to leave a comment. This would just shift the system to be gamed by bots / upvote4upvote, and keep existing hegemony in the community on who gets the power and say in porjects. Do not want.
• jinseokim 5y ago
  Whole npm ecosystem is so fragile. Remember event-stream[1]? Did we learned something from that? Yes, we might. So was it improved? Never. People are still installing 'new' colors package and wondering why its texts are broken. What if he uploaded malicious code rather than just just gibberish? What if he uploaded on only npm and not on GitHub? Would we even notice that? [1]: https://github.com/dominictarr/event-stream/issues/116 https://github.com/dominictarr/event-stream/issues/116
• vbezhenar 5y ago
  Here's my 2 cents how build system should work. I'm not sure that any build system works like that... But anyway. All dependencies sources must be included with project sources. When you check out repository, you should have everything necessary for building the project. Sources should be in their original form, so you could fix anything quickly. Libraries builds must be reproducible. Output artifacts hashes must be provided along with sources. It means that one should be able to download pre-built artifacts from the Internet. But if they're not available, that should not be an issue. Ideally whole build environment should be part of project, something like docker container. So your compiler and necessary build tools are fixed as well. Of course there should be some tooling to check for new dependencies versions, print changelogs if available, etc. But it must not be automatic.
  • strager 5y ago
    > All dependencies sources must be included with project sources. This sounds great for applications. But for libraries, you'll likely end up with the diamond dependency problem: an application uses two libraries, and each library uses their own copy of a third library.
    • vbezhenar 5y ago
      In Java you have to decide which version application is going to use in the end. Maven decides that somewhat randomly. Gradle have some tricky algorithms to determine which version is highest one. You can put two versions of the same library on the classpath anyway, at least without some tricks with classloaders which are not used for ordinary applications. So basically with Java you would need to flatten all dependencies and resolve version conflicts in some way (sometimes you must downgrade one library or even declare that some libraries are not compatible with each other, but that's a rare occasion). AFAIK npm uses hierarchical dependencies, so few libraries with a different versions are not a problem at all (at least if those libraries are good citizens and don't pollute global namespace or use it carefully).
      • shagie 5y ago
• brigandish 5y ago
  A quick shout out to all those who advocate code reviews because they don't trust themselves nor their co-workers, but will pull in dependencies without checking them.
• cybrox 5y ago
  This article invokes the initial impression of providing a solution while actually containing as much value as saying that we could end world hunger by giving everyone something to eat. Yes, if every maintainer would actively test their software in depth(!) on ever update in dependencies, things like this would happen less. This not only fails to acknowledge the issue that the package author intended to "highlight" but just plain rudicules it. Yes if people put in way more unpaid labor, we might end up with a better quality product. (I do not support the package authors decision, I just think this article is a shameless clickgrab)
• jh4u3h43i 5y ago
  What I love about .NET is that most of the stuff I need for backend development is provided by the standard library from Microsoft. So I tend to use 10-20x less external libraries comparing to Node/NPM.
• c0balt 5y ago
  Why should NPM even do anything? If someone decides they want to publish a 'disfuntional' version than it's the role of devs to use the older version and check before updating. NPM is just a glorified file sharing services, as it should be for JS packages, that features an associated manifest format. They should be able to transfer rights, as far as licenses allo and is reasonable, but that's about it.
• dusted 5y ago
  Yeah no.. The author chose to change his own project, that's in no way an attack. People not only pulling random code from the Internet, but also integrate it automatically without review and without as much as locking the version is the problem here if there is one. The author is under absolutely no obligation to maintain his project or to keep in some state desirable by whoever is currently using it.
• szastamasta 5y ago
  I never understood idea behind non exact version of dependencies. What’s to gain here? If I develop and test my app with given version I want it to run with given version. Not with something around, near by or similar. I want this exact version. There’s no way you can predict that even a small bugfix in library won’t break your code. Please just stop using all these lock files nonsense and allow only exact versions for dependencies. Use some upgrade tool like ncu to upgrade them quickly. I wonder who has invented this stuff and why.
  • cjpearson 5y ago
    Say you depend on foo@1.0.0, and some of your dependencies themselves depend on foo@1.0.1, foo@1.0.2, and foo@1.03. When you install you'd get 4 copies of nearly the exact same library. On the other hand, if everyone of those packages used a tilde or caret, they'd all depend on foo@1.0.3. That's the benefit, but it's not worth it in my opinion. Pin your dependencies and use a package-lock.json for transitive dependencies.
• ms4720 5y ago
  Pin your versions, this was so effective because no one pins their version for what they are using. Anyone saying it was the dick's fault and not yours needs to start owing their project. I admit that the last time I worked with node it was a cluster fuck of nested dependencies that only works through the prayers of angles above. But standards are standards, own your project.
• physicsguy 5y ago
  I have to ask the question - how would people have felt if instead of this, he’d spliced output into the package that printed a donation link to his patreon or similar on every import?
• omgmajk 5y ago
  This caused me so much headache last night, I maintain a little used package for our school that everyone can use and a sub-dep used the colors package. I was just about to give up when it was fixed out of the blue and then I found this article today.