undefined | Better HN

0 pointsanchochilis5y ago0 comments

Mirrors are great for speed and protecting you from dependencies getting randomly deleted off the public repo, but I don't think they can protect from malicious packages. They'll just get pulled into the mirror.

At my last gig (Java), developers reviewed all third-party libraries + dependencies and manually uploaded them to a private Ivy server. I don't think that could work in the Node ecosystem, where every module seems to have 100+ dependencies.

EDIT:

There's a real security vs accessibility trade-off here. You can't be a productive web developer, according to modern standards, and review every single transitive dependency that gets pulled into your application. And it's very inefficient to have individual developers at different orgs separately reviewing the same libraries over and over again.

One would naturally turn to repository administrators to enforce stricter security standards. Maybe RubyGems could review all source code for every new version of a package and build it themselves instead of accepting uploads of pre-built artifacts. But these repositories are run by smallish groups of volunteers, and they don't have the resources to conduct those kinds of reviews. And no open-source developer wants to have to go through an App Store-like review process to upload their silly McWidget library.

0 comments

thw0rted5y ago

There's even a security-versus-security tradeoff. If you manually review every dependency, are you also going to manually review every update to each of those dependencies? If you add friction to your update process, you're also slowing down your ability to incorporate security fixes. Dependencies find vulnerabilities all the time. If you capture a snapshot of "trusted" dependencies, when are you going to update that snapshot, and how long will your project be vulnerable in the meantime?

marcus0x625y ago

Right — the only way to really identify malicious packages is a line by line audit... All the way down the dependency chain. On top of that, does a typical org using these packages have developers who can conduct these audits and identify obvious back doors? What about less obvious bug doors?

ehnto5y ago

> You can't be a productive web developer, according to modern standards, and review every single transitive dependency that gets pulled into your application.

Applications I encounter use a ridiculous amount of outside tooling to do relatively simple work, and that's where I see dependencies explode most often.

When I work on package managed, env managed projects, every other day is a new environment issue, configuration issue or version mismatch. It's all a colossal waste of time. Had the project just chosen a handful of comprehensive tools and committed them to the repo, there would be no dark rituals of configuration and package management to perform. The code is in the repo, the code works with itself, life is good.

j / k navigate · click thread line to collapse