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.)
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.
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.
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.
+ 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...
Legal, shmegal.
"I've found a clever workaround for court orders" doesn't work around that bit.
magnet:?xt=urn:btih:14f146cdfaef83951ca9d3ac647e18e1977d1367
I'll wait
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 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.
http://ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdX...
> "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.
In other words, Hulk Hogan vs Gawker.
You can experiment with ipfs-backed git remotes though. That's already possible.
Bonus: there's also a IPFS git remote implementation! https://github.com/cryptix/git-remote-ipfs
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.
(And btw, We Nix users very much do hope to start using IPFS :).)
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.
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.
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.
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.
"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.
(Whether anyone's checking them is another question, but at least you can if you want to)
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.
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?
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.
- 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
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
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.
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.
Too late. Every package name on the list has been claimed already by a randomer with unknnown intentions.
It's almost as if privately controlled, centralized archives are a bad idea.
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.
Using a git repository gives you that for free.
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
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.
IMO, this could end npmjs of they don't fix the issue.
https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
Check out the pre-push, pre-receive, update, and post-update hooks.
(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.)
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.
[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)
then please use named scope as default like@cycle/core @reactivex/rxjs.
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.
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...
^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.4Proposal: 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.
If so, why is no one using this???
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.
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.
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?
Jesus. This is a disaster. At this point, the only responsible thing to do is to avoid NPM.
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...
You, my friend, are being US biased.
i take that back, npm is a security risk that should be avoided.
now i need a new package manager.
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".
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/
(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!").
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.
That said, I don't think "un-unpublishing" code (even under your own account) is the same as claiming ownership, just redistribution.
IANAL but "do whatever the fuck you want to" would seem to include literally everything including taking over the IP.
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.
"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.
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.
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.
As for the DMCA, usually not since most FOSS licenses are explicitly irrevocable, but with the WTFPL, who knows.
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.
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.
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.
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-...