Hacker News Reader

Comment by callmevlad | Hacker News Reader

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. "map", "alert", "iframe", "subscription", etc) available for anyone to register and replace with any code they wish.

Since these libs are now baked into various package.json configuration files (some with 10s of thousands of installs per month, "left-pad" with 2.5M/month), meaning a malicious actor could publish a new patch version bump (for every major and minor version combination) of these libs and ship whatever they want to future npm builds. Because most package.json configs use the "^1.0.1" caret convention (and npm --save defaults to this mode), the vast majority of future installs could grab the malicious version.

@seldo Is there a plan to address this? If I'm understanding this right, it seems pretty scary :|

[1] https://medium.com/@azerbike/i-ve-just-liberated-my-modules-...

View on HN

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".

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.

What if such a system was implemented using IPFS[0] (or similar) for storage?

[0] https://github.com/ipfs/ipfs

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.

No signatures, no (at least!) an IPFS mirror as a backup option - how can one trust NPM or the likes?!

NPM doesn't even have immutable versions. Many would love to see this improved.

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

As much as I agree, IPFS is still very much under construction and I don't think any known package managers got started after IPFS was reliable.

You can experiment with ipfs-backed git remotes though. That's already possible.

Yes the IPFS implementation might change but not the content multihash addressing. Linking to data with those addresses is the generic 'package management' that solves all these problems (references to mutable data at mutable origins, circular dependencies, data caching, namespace conflicts). The specifics of resolving links will hopefully be something we don't think about much.

I've played around with ipfs.js for resolving links into eval'd js at runtime and imagine a npm replacement would be pretty trivial. The IPFS peer to peer swarm seems stable to me but you could also dump all your hash-named files into a s3 bucket or something as a fallback repo.

gx is a generic package manager on top of IPFS that uses git-style hooks for adding per-language support. It's already being used to manage dependencies on the go-ipfs project: https://github.com/whyrusleeping/gx

Bonus: there's also a IPFS git remote implementation! https://github.com/cryptix/git-remote-ipfs

Somewhat related, I just coincidentally stumbled upon https://github.com/alexanderGugel/ied . "Upcomming Nix-inspired features", to paraphrase their README, could well prevent this debacle.

(And btw, We Nix users very much do hope to start using IPFS :).)

Git has crypto for a reason. Every package manager must have it too.

There’s already apt-get over Freenet: http://127.0.0.1:8888/freenet:USK@oRy7ltZLJM-w-kcOBdiZS1pAA8...

There is already gx package manager: https://github.com/whyrusleeping/gx

Looks like the npm team will not be removing the ability to unpublish packages - see reply by core committer "othiym23" on https://github.com/npm/npm/pull/12017

https://github.com/npm/npm/pull/12017#issuecomment-200131039

There are a lot of problems with NuGet, but they got this right. I do wish there was a way to mark a package as deprecated, though. For ages, there was an unofficial JQuery package that was years out of date.

`npm help deprecate`

Yep, unfortunately the same does not exist for NuGet.

Read the whole thread. Rather concerned by the final one. "Locking temporarily" to get away from the discussion?

That feels sort of like the online discussion equivalent of sticking your fingers in your ears and going "la la la I'm not listening".

I don't expect someone in their position to be unable to ignore a conversation and "take a break" but I would expect them to be capable of doing so without resorting to "suppressing" the ongoing group discussion.

Or it's a "we're discussing internally, and would rather not deal with the shit-show that Github issues becomes once the issue becomes politicized and rampant misinformation and misguided activism take over."[1] There will be plenty of time for people to froth at the mouth and complain that they chose one way or the other once they've made a clear decision, which as of the locking the thread to collaborators, they have not (the current thinking has been outlined, but they said they are thinking about it).

1: See the recent systemd efivarfs issue at https://github.com/systemd/systemd/issues/2402 and associated HN discussions, which was solved through a kernel fix. Pitchforks abound.

I suspect your right, but honestly... His choice of language sounded much less like 'were thinking as a team', and much more like 'your all talking too loudly, you've given me a headache, so i'm going to shut you all up for a while'.

You mean the response that says, verbatim: "I'm thinking about the points that have been made, and I'm sure that we as a team will consider them going forward" ? Sure, he also says for now the behavior won't change, but that's the sane thing to do with the errors are rare, as changing something too quickly may introduce new bugs or unforeseen problems. Honestly, your interpretation of that comment is the exact reason why it's good to shut it down for a little while. The conversation gets so charged that even a "we need time to think about it" response is viewed negatively.

> And... I kind of want to say "once it's published, it's forever".

This is effectively the norm with more traditional, curated package managers. Say I release a piece of open source software, and some Linux distro adds it to their package manager. Under a typical open source license, I have no legal right to ask them to stop distributing it. They can just say "sorry, you licensed this code to us under X license and we're distributing it under those terms. Removing it would break our users' systems, so we won't do it."

The difference is that NPM is self-service - publishers add packages themselves, and NPM has chosen to also provide a self-service option to remove packages. I honestly wouldn't have a problem with them removing that option, and only allowing packages to be removed by contacting support with a good reason. (Accidental private info disclosure, copyright violation, severe security bug, etc.)

  I honestly wouldn't have a problem with them removing that option, and only
  allowing packages to be removed by contacting support with a good reason.
  (Accidental private info disclosure, copyright violation, severe security 
  bug, etc.)

Even Rust's Cargo won't allow you to revoke secrets [1]. I think this is the correct policy.

[1] http://doc.crates.io/crates-io.html#cargo-yank

Aside from secrets there is also sensitive data. If someone accidentally uploads some personal information, they need a way to remove it if, say, they receive a court order ordering them to remove it.

I'm not sure how the court could force you to do something you can't possibly do...

They would force the provider to facilitate the removal.

"So what you're saying is, your computers cannot possibly not continue damaging the plaintiff's interests." "That's correct." "You're being honest with me." "Yes, your Honor." "Will the computers continue harming the plaintiff's interests if shut off?" "... That would be dreadfully inconvenient, your Honor." "Do you have a more convenient solution?" "No, your Honor." "You are hereby ordered to turn off your computers in 48 hours." "... You can't do that." "I can do a lot of things, including jailing you if you disobey my lawful authority. 48 hours."

Engineers often think that they are the first people in history to have thought "Hey, wouldn't it be easy to pull one over on the legal system?" This is, in fact, quite routine. The legal system interprets attempts to route around it as damage and responds to damage with overwhelming force.

How about a blockchain-based NPM? Can't take all the computers down.

Legal, shmegal.

Yep, but someone should implement that first. Package repositories have pretty much centralized control still, and will have for foreseeable future.

You can still be jailed for contempt of the order, though.

"I've found a clever workaround for court orders" doesn't work around that bit.

OK, now tell me how you can remove this file from BitTorrent (it's Fedora 18 KDE)

magnet:?xt=urn:btih:14f146cdfaef83951ca9d3ac647e18e1977d1367

I'll wait

It's not about whether the removal is logistically possible, it's about whether a court can punish someone for failing to carry out the removal.

Even when the former is actually impossible, a court could still punish for the latter. "Ha ha ha I use technology to cleverly show how futile your orders are" is not the kind of thing you want to say to a court with broad contempt powers.

If the "forbidden" action was previous to proceedings and carried out in good faith by unknown parties, it would be very hard to sanction anyone.

The court can't punish you for not being able to do the impossible. That's ludicrous. "We have shut down all of our servers, yes. We can't stop people from downloading this, no"

Pay damages, then.

Pay damages because someone else uploaded something by accident and you can't fix it? It doesn't work like that.

It only doesn't work like that in the context of safe harbor laws.

If the safe harbor law protection doesn't apply, and the defendant is responsible for the illegal behavior, the defendant can absolutely be held legally liable and pay the legally-appropriate punishment.

Why should you pay the damages for something that's not on your server?

That's because all laws make sense and all people who enforce and judge them are understand this.

that's why we'll kurtzweill ourselves into the computers that can't be shut down!

Would that work if you did it before the court order?

No.

Just live outside of the United States, and you'll be fine.

Yeah, there's literally no other courts outside the USA.

Yeah, because the US doesn't have treaties with most of the world...

Or something like http://ipfs.io/

IFPS is cool, however pretty far away from being usable as a package management system... Some package management system could use it as a backend, though.

In fact, gx[0] is such a package management system.

[0]: https://github.com/whyrusleeping/gx

Huh NPM already handles git?

http://ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdX...

npm already replicates to hundreds of other servers. Right now, it is practically infeasible to actually remove packages permanently.

> The legal system interprets attempts to route around it as damage and responds to damage with overwhelming force.

In other words, Hulk Hogan vs Gawker.

What Patrick says is technically true. But before granting the "extraordinary remedy" of an injunction, U.S. courts would apply the traditional four-factor test, which includes assessing:

+ the balance of hardships between allowing the conduct in question to continue vs. issuing the injunction;

+ whether the damage being caused by the conduct in question could be satisfactorily remedied by a payment of money as opposed to a mandate or a prohibition; and

+ (importantly) the public interest.

See, e.g., the Supreme Court's discussion of the four-factor test in eBay v. MercExchange, 547 U.S. 388 (2006), https://scholar.google.com/scholar_case?case=481934433895457...

That's why I'm looking into IPFS(https://ipfs.io) as part of my infrastructure. How that would look then, with IPFS...

> "So what you're saying is, your computers cannot possibly not continue damaging the plaintiff's interests." "That's correct."

> "You're being honest with me." "Yes, your Honor."

> "Will the computers continue harming the plaintiff's interests if shut off?" "No it wouldn't, your Honor.".....

And suddenly things like NPM can transfer the data to other machines, and those machines themselves can also provide to others. Deletions are impossible if people still want the content.

And IPFS guarantees that if a single node has the data, then any node can download it and also be part of the cloud that provides the data. Once it's out, it's impossible to retract.

This why sites that don't allow package authors to "unpublish" have contact information so that data deletion can be handled on a case-by-case basis.

If they receive a court order, and there is no technical way to do that, then the court is out of luck. "A court might order it in the future" is not a design constraint on your decisions today.

Sure there's a technical way to do it: you unplug the server hosting it (or more likely, your hosting provider does that for you).

No court is going to shed any tears over fact this has wider consequences than if you'd been able to comply with a narrower takedown request.

This combined with the cost of hosting (I remember the ruby community freaking out over rubygems costs a couple years ago) makes me think maybe we're evolving towards decentralized dependency hosting. Something like Storj where users offset hosting fees with blockchain payments when dependencies are fetched.

The go solution seems more reasonable and achievable- the host is part of the namespace. Instant decentralization.

There's nothing preventing decentralization with npm now; it's a matter of configuration. Tying the namespace to a host seems more like instant excessive coupling.

Tying namespaces to a hostname isn't really that controversial -- it's no different than email.

If you want to be your own provider then host your packages on your server(s) and tell your users to add npm.cooldev.me/packagename to their configuration.

If you don't want to host your own then you can choose from a few public providers like npmjs but then have to be subject to their guidelines, policies, and fees.

Throw in some automatic bittorrent support in the client to help offload costs and you've got something great.

npm already supports all of that except the bittorrent bit, with the proper configuration, and without requiring that idiosyncratic namespace convention. [0] I don't think bittorrent is actually relevant to most use cases. Most people complaining here just don't want their site to go down, so they should vendor or fork all their deps and run their own registry to support that. Downstream users of public modules can either go through npmjs or perform the same vendoring and forking work themselves.

[0] https://docs.npmjs.com/misc/registry

There have been links to child porn in the Bitcoin blockchain. To date, this has not resulted in any courts preventing full nodes from running in the US.

This is what happens with Clojars. It is possible to remove packages, but it requires a manual email to the admins, along with an explanation, e.g. published internal lib accidentally. This prevents scenarios like this, but also cases where people want to 'clean up' things they no longer need, even though others are depending on them.

That's a good idea, but what if Kik lawyers come knocking on your door saying that you're breaking the law and this package cannot stay there forever, or for any moment longer?

Well it shouldn't be hard...oh wait. This is javascript. Good luck then. :)

I think I'd just want to add that namepsacing by author doesn't entirely fix the problem. For the fewer instances where there is a collision, we still have this issue with lawyers asserting trademarks.

"Would the real Slim Shady please stand up?"

We want multiple 'kik's and multiple Shady's simultaneously. So record the gpg sig of the author in package.json, and filter the name + semver against just their published modules when updating.

Depending on how unique you need to be:

npm install <module> --save

npm install <author>/<module> --save

npm install <gpg>/<module> --save

On a side note, npm-search really sucks. It lacks a lot of fine-grained filtering. I'd love to be able to search by tags, or exclude results with an incompatible license, or even prioritize results by specified dependencies. npm-search needs love.

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.

Most of the programming language Package managers that I've seen either don't have the facility or it's not widely used.

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)

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.

There's a plugin for checking it in maven ( 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?

Version ranges can create inconsistent builds. That's why they're not default and that's why they're not really recommended.

A spectacular failure just waiting to happen.

For example, RubyGems it's possible to sign them, but it's not used as much as it should be because option security never gets used. Waxseal is a gem to sign other gems.

Generally though, it's a worse vulnerability than bitsquatting because it gives quarter to silent, advanced, persistent threats by definition. (Dynamic, untrusted code modification either in-flight or at-rest in difficult to prevent/audit ways.)

The primary way for change to happen is for some company to get hacked, but then it will only change for that one platform because most people are reactive not proactive. Changing this proactively seems painful, but it's less onerous than the risks of the alternatives. The key point is to make end-to-end verification and public key management mandatory and simple.

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

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.

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.

I edited my post while you were writing yours ;-) Thanks for the clarification.

> 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.

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.

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.

Without IPFS, pretty sure authorities can order to take down the repository and all of the forks.

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.

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.

IPFS with public keys per developer and signing of packages would solve that.

About your third point, discoverability and optimization of dependency resolution can be solved by a proxy, in a decentralized system, like the one used in Go.

Hasn't hurt Java devs any. Although we have plenty of mirrors and no concept of unpublishing.

Except Go isn't GitHub specific, I could use BitBucket, Gitlab, or any service I setup myself. Even locally, just like git itself I suppose. Go supports other tools like Mercurial as well as others.

It's just as bad. Commits can be re-written and/or deleted. I've always been surprised that anyone thought release management based on SCM commits was a good idea. It's not.

This seems like a serious security risk. Is there any solution? Would using version numbers without the caret work?

Signing using private key?

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.

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).

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.

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

I don't get it. If I keep a hash of every dependency in my project, and an attacker change a dependency, I will detect the attack by computing the dependency hash and comparing it with the one stored in my project (for example in the dependencies lock file), which cannot be changed by the attacker.

> ...which cannot be changed by the attacker.

That's fine on your personal system, where you manually update your package's dependencies and manually update the hashes of your package's dependencies.

Now, what happens if an attacker compromises the repo where people download your package from? Or what if he executes a MitM attack on the repo or a user who downloads from it? He can change the entire package, including all manifests, all hashes, etc. Users who download it will be none the wiser. By the time someone notices and corrects it, people will have downloaded the compromised versions and be infected.

The only thing that protects against this is strong crypto signatures. For example, if a Debian mirror were compromised and an attacker uploaded compromised packages, users would be safe, because apt would refuse to install the packages, because they would fail signature verification.

Please read the link I gave. It explains everything in detail.

Not only is there a solution, but it's pretty well known computer science. Use public key cryptography to create a digital signature. It's not even a novel use of this -- .NET has been using this to sign assemblies and packages from day one.

I think he means a solution to the current problem of the packages being replaced with malicious ones, not the problem with npm not supporting package signatures.

Package signing by the package's author /is/ the solution, right? This way the only entity that can publish a valid update is the the package author. This still has the problem of bootstrapping the trust relationship, and leaves the door open to the author publishing a malicious but signed package or the signing key being stolen and used to do the same. However if you don't trust the package author to be responsible or take precautions against the keys being stolen then you're essentially taking on the burden of implementing of your required functionality.

We also need some way to link packages to authors. In the Java world packages are supposed to be in a namespace that's the reverse domain name, so you could (potentially, theoretically) connect that up with something like DNSSEC and enforce that people can only publish packages for domains that they control. (Though even that is really just punting the problem up to the DNS registries).

I like your use of "Look, even .NET does this, people".

You can use github and get namespacing under the author.

IMO, this could end npmjs of they don't fix the issue.

And always use head? I think we still need versioning (potentially fuzzy). Also, isn't that what bower does/did?

You can provide any tag, sha, or branch which can be supplied as an argument to git checkout.

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.

You do, actually, if you've setup the git repository correctly.

https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

Check out the pre-push, pre-receive, update, and post-update hooks.

Those hooks aren't tracked in the repo though, are they? In many cases that will be inconvenient.

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.)

Well, sure, but that's complicated, and ".scripts.prepublish" in package.json is not. I'd love to have the git knowledge to do what you've described here without googling and frowning, but I don't have that yet, and I've been using git for years. Whereas I could use package.json to accomplish the same task on basically the first day I used npm.

Also explaining nicely with real life to the face why you should only use specific versions, or at least specific ranges for your dependencies.

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?

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.

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 (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/

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.

That's how it used to be, more or less. Then they commercialized "to better be able to support the infrastructure".

All the more reason to seek better alternatives?

That's not how it works. You can't publish left-pad 0.0.3 again.

Unless you're npm: https://twitter.com/seldo/status/712414400808755200

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.

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.

Or, you know, prefix with author's username, a la Github.

Like, can my github username be kik? And if I have created years before they founded kik?

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!").

Ding Ding Ding!!!

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/

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?

That's a good point. Very inconsistent behavior by NPM here.

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.

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?

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.

Notice that I didn't talk about the node package manager, but about the author and the company NPM Inc. (and their registry service).

It's not that your "build got broken", it's that you had a broken build process. You are the one at fault. You chose (perhaps unconciously) to rely on various entities, their services, their whims, and they proved to be unreliable.

The simplest solution for those who write an application is to commit the dependencies into the repository as well. This significantly lowers the amount of entities relied upon when building it. (Alternatively, have your own registry, whatever.)

Then you can discuss issues like the ideal module granularity, ethics of this or that actor, names and trademarks, etc. without worrying about your "broken build".

Well, now I'll upvote you for saying something else that seems wise, so it's all good.

> 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.

Jesus. This is a disaster. At this point, the only responsible thing to do is to avoid NPM.

I feel like the best way to avoid a disaster like this is for developers to avoid using registered brand names when they write their packages.

It's not difficult, since there are all sorts of rights brand owners can't get you on.

1. You don't really need a catchy name for an open source project, since you're not in competition for funds. Call it something descriptive. Descriptive words can't usually be protected, so you should be fine.

2. In most countries, using your personal name is fine irrespective of any IP rights.

3. If you want to use a catchy name anyway, check on the USPTO TESS database for registered rights. If any are live, choose another name.

Remember when Groupon tried to register Gnome for software applications[0], and the open source community (rightly) came out in force supporting the Gnome foundation? But when it's the other way round, it makes no difference.

The problem isn't IP law, it's just bias.

[0] http://www.pcworld.com/article/2846632/groupon-decides-to-le...

...and do the same for the 200+ or so independent countries in the world with their own databases?

You, my friend, are being US biased.

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?

> 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.

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 :)

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?

The WTFPL's own website mentions that it's never been tested in court.

> 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.

Uh... which part of "DO WHAT THE FUCK YOU WANT TO" is actually unclear here? Is there a word or phrase that you're not grasping?

"DO WHAT THE FUCK YOU WANT TO" clearly includes not only taking over the IP but also RE-LICENSING IT under whatever terms you like. That's kind of what "DO WHAT THE FUCK YOU WANT TO". Do. What ever the fuck. You want to.

How is this unclear? I'm kind of baffled.

Licensing doesn't really have anything to do with copyright / trademark / IP in general. It just grants you the ability to use something in the way specified.

I'm not aware of case law where a license has been able to move the original IP from one party to another; I've only heard of that happening through standard legal documents.

But I also pointed out that I wasn't sure how it would shake out anyway and was seeking feedback.

But why are you saying the copyright was transferred? I don't see anything that implies that. Someone got a copy of the code under an irrevocable license that grants them to right to re-publish it, and that's what they are doing.

> But why are you saying the copyright was transferred?

I don't think I did?

> I don't see anything that implies that. Someone got a copy of the code under an irrevocable license that grants them to right to re-publish it, and that's what they are doing.

Yeah mostly curious if the original author could, say, use the DCMA or something similar to force npm to take it down if he really wanted to.

I mean, you mentioned "take over the IP" and "move the original IP from one party to another", but I don't see why you're asking that, as NPM hasn't taken over any IP (nor has the new user), they simply redistributed the code.

npm didn't take it over, another user did and npm helped re-publish the unpublished version. I already answered the why I asked that..."mostly curious if the original author could, say, use the DCMA or something similar to force npm to take it down if he really wanted to."

But the user didn't take over the IP, it only took over the name on NPM's registry.

As for the DMCA, usually not since most FOSS licenses are explicitly irrevocable, but with the WTFPL, who knows.

> But the user didn't take over the IP, it only took over the name on NPM's registry.

That's almost the same thing. Like if someone dropped their domain name and you grabbed it up. The customer / user isn't going to notice a difference but it's now being represented by someone else.

I don't think anyone cares enough to really do anything about this though. Mostly curious if it was possible to do something about it but I'm guessing the waters are pretty untested.

Post Berne, I believe copyright is the default. It may be WTFPL but it appears to be surprisingly hard to actually put something into public domain based on the brief reading I've been doing.

> Granted the license is WTFPL but does that include taking over the IP itself?

In some jurisdictions you have "moral rights" in addition to your copyright - but even in those, I'd expect the WTFPL constitutes a license to falsely claim authorship of the covered code. I mean, the text pretty clearly authorizes you to do so on its face, and courts lean pretty strongly towards reading words under their plain, normal meanings. IANAL.

IANAL either, but moral rights are often (usually?) inalienable, so I doubt any license can waive them in those jurisdictions.

That said, I don't think "un-unpublishing" code (even under your own account) is the same as claiming ownership, just redistribution.

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.

No it won't... The caret specifier for 0.0.x packages means "this version and this version exactly".

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

And to be honest, it's news to me. Sorry i impulse downvoted you...

No problem! It's not super well-known since they switched from tildes to carets and tildes didn't behave that way.

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

Why dont they just use that version notation ? (>=0.0.2,<0.1.0) will be much simpler

For every single dependency in most projects that honor semver? ^ is just an extremely convenient shorthand.

You're right, I added an edit to my comment.

That's an interesting side effect.

Wouldn't (shouldn't) npm block same named modules from being uploaded with a different username?

Proposal: go with a java based naming system: com.yc.mymodule.

All installations would require the user to use com.yc.* in package.json and all users would be required to register as a com.yc style organization name. Thus only one user can remove/add that exact module.

npm has namespaces, but they are optional and not hugely adopted as of yet.

Hmm but then is the scope/namespace reserved for each user that reserves/uses it? If I publish @andy9775/left-pad can someone publish under @andy9775/other-module or can only I publish under @andy9775/...?

If so, why is no one using this???

Yes, namespaces are specific to your username. Nobody else can publish packages under your username namespace.

I think it's less common because it was released along with private modules and is often conflated with them. Basically all packages are still namespace-less. TBH I never thought about the benefit they'd have until now.

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.

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.

I wrote to kik's chatbot, maybe she has a heart https://twitter.com/andrejlr/status/712887779185831936?s=08

As I understand it, even if a package is unpublished, that does not (normally) free up its name.

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-T...

Reply on news.ycombinator.com