Live data from Hacker News

I've Just Liberated My Modules

medium.com

591–600 of 827 posts

Re: I've Just Liberated My Modules

#591
post #66
post #29

Earlier quoted context omitted.

I'm using npm / browserify etc in anger for the first time today. This is a horrible issue to have run into and it's left a pretty sour taste. The fact that it's possible for someone to unpublish 17 lines of js and break the install of major bits of infrastructure for everybody is pretty insane. It seems like at a minimum the dependency tree should be traversed to see what the flow on effect will be. Should it even b…

I don't want to sound like a old grumpy man but here goes anyhow. I was looking into using node.js, react, etc after many years of writing web apps using Python and Quixote (obscure web framework like Flask). The whole Javascript technology stack looks pretty insane of me. Getting a working React environment requires a huge number of packages to be pulled down by npm. Browserify requires a bunch more. Recursive depen…

You sound like a grumpy old man.

> Recursive dependency resolution is nice and all but isn't this going to create a massive technological debt that needs to be maintained?

Keeping each package small and self-contained reduces the technical debt. If you depend on a monolithic library like Django, an update can be months of work with impact all over your code. If you depend on the same amount of code, but split into 100 smaller libraries, everything becomes much easier to maintain.

> Semver is not a magic bullet

It's pretty close. Having an ecosystem where everyone follows it religiously because all the tooling is built around it is really nice.

> Also, seems like a security disaster waiting to happen (I don't use CDN because I like to make sure I review code before putting it on my important websites).

It doesn't have to be. Reviewing all the code you depend on is a fool's errand IMO, but if you want to do it then NPM makes it very easy.

> Linux distributions like Debian have put in huge effort into making a packaging system that is secure and doesn't lead to dependency hell. You can argue how successful they have been but, and maybe I'm ignorant, I don't see the same effort and level of maturity in the Javascript/npm ecosystem.

The node ecosystem has been very good at avoiding dependency hell. It's well designed. They could stand to learn from Debian on the security front though.

Re: I've Just Liberated My Modules

#592
post #24

This is why you should vendor it. What is "it"? All of it, whatever it may be. You should be able to build your systems without an internet connection to the outside world. I say this with no reference to particulars of your language or runtime or environment or anything else. This is merely a specific example of something that could happen to a lot of people, in a lot of languages. It's just a basic rule of professi…

I'm not sure - is there a guide to setting up our own NPM mirror to prevent this happening in future?

Re: I've Just Liberated My Modules

#593
post #24

This is why you should vendor it. What is "it"? All of it, whatever it may be. You should be able to build your systems without an internet connection to the outside world. I say this with no reference to particulars of your language or runtime or environment or anything else. This is merely a specific example of something that could happen to a lot of people, in a lot of languages. It's just a basic rule of professi…

I don't think "vendoring" in the sense of copying all your dependencies into your source tree is a good idea. Source and dependencies are different things and well worth using different tools for. You absolutely do want to ensure that your builds are reproducible even if the upstream libraries go away, but there are ways to do that without putting their source in your source tree.

Re: I've Just Liberated My Modules

#594
post #559

Earlier quoted context omitted.

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.

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

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

Re: I've Just Liberated My Modules

#595

Earlier quoted context omitted.

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.

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.

Re: I've Just Liberated My Modules

#596
post #162

The problem here is that there is a single petname space (pet namespace? pet name space?) administered by one organisation but used by everyone. With a different system, the author could have a key $foo, and call his package ($foo kik), and that wouldn't interfere with (us-trademark-office kik).

As done by Maven for a decade.

But hey, Java sucks, move fast and break things, right?

Re: I've Just Liberated My Modules

#597

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…

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

Re: I've Just Liberated My Modules

#598
post #568

Earlier quoted context omitted.

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 c…

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?

Re: I've Just Liberated My Modules

#599

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…

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?

Re: I've Just Liberated My Modules

#600
post #285
post #171

Earlier quoted context omitted.

Even if Azer had relicensed the code, NPM had a copy of the code released under the original one, which can't be revoked.

Yeah, I appreciate that, but if this becomes a general concern that npm can grant ownership to whoever it deems acceptable (even to the point of republishing existing versions), then could we start seeing e.g. WTFPL with npm exceptions style licence fragmentation. The source could still be readily available to anyone to republish as they see fit, but only as a different name / version. Not condoning it, just thinking…

All open source licenses allow the licensee to republish your code - that's part of the definition. It's not going to trigger license fragmentation because any exceptions will make it not open source.

If you want to enforce that other people use different names for their forks, the usual way to do this is with trademarks - this is what e.g. mozilla and redhat do. Npm should respect your trademarks, and if someone else publishes a project under your trademarked name you can make npm take it down... which is exactly what originally happened here.

Post reply on HN