14 ms·

The fact that this is possible with NPM seems really dangerous. The author unpublished (erm, "liberated") over 250 NPM modules, making those global names (e.g.

• krainboltgreene 11y ago
  That's not how it works. You can't publish left-pad 0.0.3 again.
  • bentlegen 11y ago
    Unless you're npm: https://twitter.com/seldo/status/712414400808755200 https://twitter.com/seldo/status/712414400808755200
    • seanp2k2 11y ago
      ooh gosh, they should really do something like ban new projects from using those names until they figure out a better solution, hopefully with the module author.
      • deleted 11y ago
        [deleted]
      • deleted 11y ago
        [deleted]
      • tobltobs 11y ago
        Seems that we should now prefix any package name with a random string like 'skdjdihsawqy'. This way you could maybe avoid to be the target for some of those 'has to proof itself' lawyers.
        • melvinmt 11y ago
          Or, you know, prefix with author's username, a la Github.
          • tomaskafka 11y ago
            Like, can my github username be kik? And if I have created years before they founded kik?
            • usrusr 11y ago
              How many years before github would that be? (Edit: this was written under the assumption that the lawyers in question are working on behalf of kik, the cheap clothes company, not kik, the messenger company. The original article is unclear about that) This really has to be attacked at the root: let's all stop pretending that a sequence of characters can be owned. Before the web came along, people were completely sane about the protection of brands. Nobody had delusions about string ownership, but deceptive abuse of brand names was suppressed just as well. Enter the web, and suddenly corporations start thinking they somehow deserve exclusivity for their stupid little three-letter-acronym, at first on the DNS, now, apparently, also in search engine hit lists ("oh noes, someone might google themselves onto github instead of our site, people will start wearing NPMs instead of our clothes!").
              • fapjacks 11y ago
                Ding Ding Ding!!!
          • danneu 11y ago
            This would solve classes of issues with the npm ecosystem (many of which remind me of trying to register a domain name) like name-squatting, trying to think up a marketable-but-untaken name, and ownership transfer. OP claimed a bunch of sweet dictionary words (concat, iframe, door, bud, alert, map) and new owners are now claiming them and it's a security disaster. But it'd be a lot less interesting if they unpublished "azer/map", "azer/alert", "azer/iframe", etc. and new owners republished under their own names. Elm packages got this right: http://package.elm-lang.org/ http://package.elm-lang.org/
    • guelo 11y ago
      So left-pad is too important to be removed but Kik isn't? What if the author had originally called left-pad Kik? Why is it ok for the Kik trademark holder to break thousands of builds but not the module author?
      • artursapek 11y ago
        That's a good point. Very inconsistent behavior by NPM here.
      • bluefox 11y ago
        This is a very good question. I was going to make the argument that the author merely continued what NPM Inc. started, and that if you fault him, you should also fault NPM Inc., but then I noticed that NPM Inc. didn't unpublish his module, but transfered the name to another account, which is much worse, if you think about it. The ultimate conclusion is that if it's anyone's fault, it is the fault of the person who relies on NPM Inc. when building his software.
        • newjersey 11y ago
          I'm a known downer of npm and node in general and this illustrates how bad npm is about this... You can't just change owners to kik on npm without the previous maintainer's permission. NPM has violated the trust of the community and will continue to do so until someone forks npm and makes an honest community out of it. What's next? If I have foo.bar domain, can kik come and say I can't have foo.bar/kik or kik.foo.bar? To the people who think npm is right, what if you owned foo.bar and Google decided they didn't want to deal with kik lawyers and redirected kik.foo.bar to kik.com?
        • fungi 11y ago
          couple of days ago i was all smug from upvotes for calling npm best practise. i take that back, npm is a security risk that should be avoided. now i need a new package manager.
          • bluefox 11y ago
    • BinaryIdiot 11y ago
      That's pretty interesting. I wonder if it's within npm's legal right to distribute someone else's IP in such a way that they do not desire. Granted the license is WTFPL but does that include taking over the IP itself?
      • krapp 11y ago
        > Granted the license is WTFPL but does that include taking over the IP itself? IANAL but "do whatever the fuck you want to" would seem to include literally everything including taking over the IP.
        • BinaryIdiot 11y ago
          Yeah I get the "do whatever the fuck you want" but in a legal sense I wasn't sure that could (or did) include actual ownership. I thought that had more to do with copyright and any other IP transferring. Then again I also said I had no idea :)
          • krapp 11y ago
            The more I think about this license, the more I wonder if it's even legally enforceable. How do you enforce a license whose only terms are that it has no terms?
            • steveklabnik 11y ago
              The WTFPL's own website mentions that it's never been tested in court.
      • girvo 11y ago
        > Granted the license is WTFPL but does that include taking over the IP itself Well, I'm certainly not a lawyer, but I personally think thats in the spirit of the "Do What the Fuck You Want to Public License"... And at the end of the day the IP is still owned by the original author; the distribution of it has changed.
      • 11y ago
  • callmevlad 11y ago
    Yes, but I can publish an evil left-pad@0.0.10, and if you're not shrinkwrapping or any sub-dependency has left-pad: "^0.0.3", it will pull in the evil 0.0.10 version. EDIT: I stand corrected. See below, looks that's not the case specifically for "0.0.x" versions, but gets progressively more relaxed if there's a non-zero minor version specified. However, many of the unpublished packages had varying major and minor versions, which would have the more loose caret range behavior.
    • chrisfosterelli 11y ago
      No it won't... The caret specifier for 0.0.x packages means "this version and this version exactly".
      • deleted 11y ago
        [deleted]
      • Klathmon 11y ago
        He's right, for `0.0.x` versions it means "this version and this version exactly" https://docs.npmjs.com/misc/semver#caret-ranges-123-025-004 https://docs.npmjs.com/misc/semver#caret-ranges-123-025-004 And to be honest, it's news to me. Sorry i impulse downvoted you...
        • chrisfosterelli 11y ago
          No problem! It's not super well-known since they switched from tildes to carets and tildes didn't behave that way.
      • nmjohn 11y ago
        Some examples of how it works: ^1.2.3 := >=1.2.3 <2.0.0 ^0.2.3 := >=0.2.3 <0.3.0 ^0.0.3 := >=0.0.3 <0.0.4
        • ybrs 11y ago
          Why dont they just use that version notation ? (>=0.0.2,<0.1.0) will be much simpler
• vjeux 11y ago
  Ideas for improvement: - Add 2 factor authentication for npm publish - When you npm install, add a warning for all the versions that got published without 2 fac - pre-install/post-install scripts should require user to accept or refuse. The simple action of running npm install shouldn't run arbitrary code. - make shrinkwrap by default (and fix all the issues with it) so that running npm install doesn't use different versions when used over time. - make updating a version an explicit decision via npm upgrade
  • deleted 11y ago
    [deleted]
  • d0m 11y ago
    Hmm, how does that help? User A: Publish package X1.0 (with 2 factor auth) User B: Download with npm package X1.0 User A: Unpublish package. User C: Publish package X1.0, malware code (with a different 2 factor auth) User B: Somewhere else, download and install package X1.0 For that to work, every package should be signed in package.js so that when you download a different version, you know about it. Also, I don't think it should be possible to alter previous versions. Package X1.0 should always be X1.0. EDIT: Seems like it's impossible to re-upload X1.0, which fix this issue. I thought once a package was unpublished, it was possible to republish the exact same version.
    • STRML 11y ago
      When a package transfers ownership or is removed/re-added, it's not possible to republish the same version as one that has previously existed. Of course, this doesn't save you if you're installing `^1.0.0`, the maintainer deletes the package, and someone else uploads a malicous `1.0.1`. The package.json should allow pinning publisher usernames and optionally public keys, and shrinkwrap should pin hashes, not just versions.
      • d0m 11y ago
        I edited my post while you were writing yours ;-) Thanks for the clarification.
• jonahx 11y ago
  This seems like a serious security risk. Is there any solution? Would using version numbers without the caret work?
  • deleted 11y ago
    [deleted]
  • throweway 11y ago
    Signing using private key?
    • deleted 11y ago
      [deleted]
    • ngrilly 11y ago
      There is no need to sign. Just keep a cryptographic hash (SHA256 is a good bet) of the package in the dependencies manifest, and check it after download. Using a git repository gives you that for free.
      • grincho 11y ago
        SHA1 collisions are affordable for large actors now and getting cheaper all the time, so git, with its SHA1 assumptions hard-coded, unfortunately doesn't protect you anymore. But the local hash approach is a good one, proven in pip 8 (Python) and npm-lockdown (JS).
      • throweway 11y ago
        More for new versions of same software where the account might be highjacked but hopefully the key wasnt. I dont think a hash would help.
      • alphapapa 11y ago
        Attacker changes package, then changes hash in manifest to match. Checks pass, users are compromised. Attacker clones git repo, creates new commit with trojan, pushes to repo with compromised credentials. New users clone compromised repo, others pull and fast-forward. All hashes are valid. You need to read the Strong Distribution HOWTO: http://www.cryptnet.net/fdp/crypto/strong_distro.html http://www.cryptnet.net/fdp/crypto/strong_distro.html
• coroutines 11y ago
  So we need gpg signed packages :> And... all packages should be namespaced under the author who published them. And... I kind of want to say "once it's published, it's forever".
  • andrewfong 11y ago
    GPG isn't strictly necessary if you trust NPM's authentication system (of course, that's a big "if" for many folks). Publish forever (barring requests to remove for legal compliance or whatever) is a good idea. Or at the very least, it should be a default option. And if you install a dependency that isn't "publish forever", you should get a warning.
  • cookrn 11y ago
    What if such a system was implemented using IPFS[0] (or similar) for storage? [0] https://github.com/ipfs/ipfs https://github.com/ipfs/ipfs
    • smaddox 11y ago
      I'm surprised all package managers don't use an IPFS-like system that uses immutable state with mutable labels and namespaces. Now that IPFS exists, and provides distributed hosting, it's even easier.
      • nikolay 11y ago
        No signatures, no (at least!) an IPFS mirror as a backup option - how can one trust NPM or the likes?!
      • kylecordes 11y ago
        NPM doesn't even have immutable versions. Many would love to see this improved.
        • jakub_g 11y ago
          What you mean by that? It used to be possible to republish a version (it broke our build when a dep was republished with a breaking change, that's how I learnt about it) but this was fixed some 2-3 years ago IIRC
• overgard 11y ago
  Do they seriously not use any sort of public key cryptography to sign packages? Frankly, for a project that's been around as long as NPM, that's downright irresponsible if that's the case. That's like package management 101.
  • raesene4 11y ago
    Most of the programming language Package managers that I've seen either don't have the facility or it's not widely used.
    • lmm 11y ago
      Maven central requires GPG signatures for every package, so all major libraries on the JVM have GPG signatures. (Whether anyone's checking them is another question, but at least you can if you want to)
      • mike_hearn 11y ago
        I really doubt anyone checks them. It's not integrated or enabled by default, there's no way to pin keys in the build files, etc. GPG isn't the solution to such problems, unfortunately. In one of my old projects (bitcoinj) we did write a Maven plugin that let you put the hashes of the dependencies into your build file. However it's rare to see Maven/Gradle builds that accept version ranges. And once downloaded it's cached.
        • lmm 11y ago
          There's a plugin for checking it in maven ( http://www.simplify4u.org/pgpverify-maven-plugin/plugin-info.html http://www.simplify4u.org/pgpverify-maven-plugin/plugin-info... ) that allows pinning the keys. Ranges are rare but I'm not sure why - maven actually has very good support for them. I guess it's just that they're not the default?
          • oblio 11y ago
• spinlock 11y ago
  You can use github and get namespacing under the author. IMO, this could end npmjs of they don't fix the issue.
  • domoritz 11y ago
    And always use head? I think we still need versioning (potentially fuzzy). Also, isn't that what bower does/did?
    • tdvorak 11y ago
      You can provide any tag, sha, or branch which can be supplied as an argument to git checkout.
  • jacobr 11y ago
    You don't get any prepublish hook when pushing to a git repository though, so you can't do things like preprocess with babel, typescript, etc, unless you check in the compiled source.
    • nostrademons 11y ago
      You do, actually, if you've setup the git repository correctly. https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks Check out the pre-push, pre-receive, update, and post-update hooks.
      • jessaustin 11y ago
        Those hooks aren't tracked in the repo though, are they? In many cases that will be inconvenient.
        • nostrademons 11y ago
          They're placed in the repo itself, under .git/hooks, rather than in the working tree. If you want to version them, you can always place a symlink in .git/hooks and have it point to a file inside the working tree. Note that this won't work for bare repositories (which have no working tree), but usually in that case you want a separate deploy process where a sysadmin (or build script) manually copies over files, to prevent a random dev from borking the repository, which a bad update hook can easily do. (This doesn't help with the GitHub case. But then, as we saw from the recent CocoaPods story, using GitHub as your CDN is probably not a great idea either.)
• z3t4 11y ago
  Because NPM knows a module has been unpublished, it can try to be smart about it and change existing package.json so there will be no more updates to that module. I also think dependencies should be non-flat/tree/static. So that you only have to trust one dependency, and not all of it's child dependencies and their dependencies too. You should only need to manage your own dependencies, not other peoples dependencies. There should also be a way to contact everyone who use your module, so you can tell them about critical bugs etc.
• ludamad 11y ago
  All the more reason to seek better alternatives?
• cliveb 11y ago
  NPM could go blockchain. Tune for fast commits, eventual consistency and slow deletes. Slow enough to allow modules with global names to be replaced. https://github.com/ethereum/wiki/wiki/Ethereum-Development-Tutorial https://github.com/ethereum/wiki/wiki/Ethereum-Development-T...
• giancarlostoro 11y ago
  I'm left thinking of how Go does it, whereby repositories are downloaded via git or whatever version control software's URL. Making it impossible for the admins of "NPM" to take down a package. Add in IPFS and you've got one heck of a "package manager" I guess Go's approach is not really a "package manager" but nobody can truly stop you from downloading from a git repository, and if they do, you can go to the forks etc.
  • blackskad 11y ago
    The vendor experiment provides a nice solution to that problem. Check in the vendor directory into your own repository and you always have the required source code available, even after the original author removes his repository on github.
  • cronos 11y ago
    Without IPFS, pretty sure authorities can order to take down the repository and all of the forks.
  • r0muald 11y ago
    The same can happen with GitHub repositories, though, that is how the vast majority of Go packages get published. It's almost as if privately controlled, centralized archives are a bad idea.
    • tragic 11y ago
      1. However, it would deal with GP's problem - that is, that somebody else could upload a package with the same name as one of the ones removed and cause ... surprises the next time someone runs npm install. Github repos are namespaced to their owners, at least, radically reducing the potential for this kind of thing. 2. /s/github/whatever . As long as there's a public URL from which something can be cloned, the idea still works, as long as that URL doesn't someday point to something completely different. Again, not impossible, but less likely than with NPM. 3. There are, like it or not, real advantages to centralised archives - discoverability, optimisation of dependency resolution, etc. 'Privately controlled' is an elastic idea - it seems to me that there's a difference between a non-profit foundation, say, and a for-profit company like NPM or GH, but both are 'privately controlled'. The question is whether these advantages outweigh the disadvantages. In my opinion, they do.
• erikb 11y ago
  Also explaining nicely with real life to the face why you should only use specific versions, or at least specific ranges for your dependencies.
• namelos 11y ago
  could we just move our javascript package manager to an organisation rather than a commercial company? then please use named scope as default like@cycle/core @reactivex/rxjs.
  • joepie91_ 11y ago
    That's how it used to be, more or less. Then they commercialized "to better be able to support the infrastructure".
• scoot 11y ago
  > Is there a plan to address this? Too late. Every package name on the list has been claimed already by a randomer with unknnown intentions.
• antihero 11y ago
  Legally isn't it totally NPM as a company to publish existing versions of left-pad because those versions were already released under a license that allows redistribution, whether the author wants them to or not? Or can the author effectively veto this?
  • ShaneCurcuru 11y ago
    Good question. Under something like GPL or Apache, npm (or anyone, really) would have a clear legal reason to continue using and redistributing the code; there's nothing the copyright holder can do about that (unless you actually violate the license terms). Under WTFPL, that's certainly the intent of the license, but I haven't heard any court declaring a case based on WTFPL, so you don't actually know what the courts would make of it. But in general, yes, I'd bet a court would let people do what the f* they wanted once they got some code under WTFPL. The separate question is: ethically or business-wise, do they want to continue publishing code from an author who explicitly tells them not to? Legally they (almost certainly) could, but as a FOSS business, would they want to? Software Licenses are pretty easy for the basics - after you read the whole thing.
  • dkersten 11y ago
    From what I can tell[0], left-pad was released under the "Do what the fuck you want public license"[1], so I suppose NPM can do whatever the fuck they want, including redistribution. [0] https://www.npmjs.com/package/left-pad https://www.npmjs.com/package/left-pad (although I suppose its possible the library was added after the package was re-added -- I don't see a license on the GitHub page) [1] http://www.wtfpl.net/ http://www.wtfpl.net/
• joepie91_ 11y ago
  As I understand it, even if a package is unpublished, that does not (normally) free up its name.
• dre-hh 11y ago
  I wrote to kik's chatbot, maybe she has a heart https://twitter.com/andrejlr/status/712887779185831936?s=08 https://twitter.com/andrejlr/status/712887779185831936?s=08
• Too 11y ago
  This is extremely severe. Any package i install might after x levels of sub-dependencies pull in one of these names which are potentially pwned. React and Babel pulled in a few of them to take some well known examples. I would say the whole npm is pwned until these packages are either restored or that the package name is blacklisted/reserved. Is it possible to blacklist packages locally so I get warned if they are pulled in as sub dependencies? I don't trust every package maintainer to be quick enough to remove these dependencies.