Hacker News Reader

Comment by gbuk2013 | Hacker News Reader

gbuk2013

I came across this interesting rant the other day: https://github.com/uNetworking/uWebSockets.js/blob/master/mi...

It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)

View on HN

Nothing that couldn't be automated; in Go land this is (arguably) called vendoring (https://go.dev/ref/mod#vendoring). Good to offload or reduce dependencies on 3rd party dependency hosters, pull a dependency into your own code review tools, and to ensure reproducible builds long term.

I mean there’s nothing stopping you from committing node_modules to git (after running something like https://github.com/timoxley/cruft on it) and reviewing code changes on dependency updates.

I even managed to make that part of the workflow on one team I worked with but several other teams since thought it was a crazy idea. :)

It's a generic and very old term for committing dependencies to your repo, it's not go-specific.

I think the general idea that your supply chain should be rooted in source repositories and associated commit hashes is the right one. Tooling can be made to automate the process of putting together a product from those defined sources. Some languages/systems already have some support for this. E.g. Golang and Rust. The concept of a "binary" artifact is really dead now everyone uses git and builds are quick. It lives on in things like npm and docker hub but we don't actually need it.

DUB , for D Lang does that.

The problem would be the dependencies of your dependencies, and keep going many levels.

But presumably, you only include dependencies that you trust and those dependencies themselves do their trusting more strictly than you. Trust is built on vetting, signatures and reputation.

That is, at least what we do, in theory. In practice, we cross fingers and let the LLM pick dependencies, are satisfied if it just works and we either update our deps frequently or infrequently.

> Trust is built on vetting, signatures and reputation.

https://news.ycombinator.com/item?id=47017833

Well, now with an irony, but sadly, of course.

Would Red Hat be considered a trusted/reputable vendor? :-D

The problem is that node.js doesn't have a good standard library so one must rely on external packages to build even basic apps.

Can you tell us what exactly is missing? A network api? Process execution? IO? Math?

From this we can see a few patterns: https://www.npmleaderboard.org/

Node.js doesn't have good support for regex, handling files, streams, serving static html, routing, operations on lists/dicts.

Built Packj [1] to audit dependencies easily from CLI.

1. Packj (https://github.com/ossillate-inc/packj) detects malicious PyPI/NPM/Ruby/PHP/etc. dependencies using behavioral analysis. It uses static+dynamic code analysis to scan for indicators of compromise (e.g., spawning of shell, use of SSH keys, network communication, use of decode+eval, etc). It also checks for several metadata attributes to detect bad actors (e.g., typo squatting).

That might change the odds, but unless you fork diligently (and monkeypatch each and every future vulnerability) you might ship a compromised fork forever.

Except most of the attacks so far has not landed actually source code changes to git IIRC. They have targeting the release files directly.

Software vulnerabilities are often not placed maliciously, and are present in the original source. If you don't patch them if discovered later, you'll be vulnerable to them.

Yes. Isn't that "giant PITA" is referring to here?

> your own repo reviewing and merging from upstream as needed. Would be a giant PITA though

The problem is the volume of dependencies. Most modern JavaScript, Python, Rust, Go, etc. projects have many dozens of transitive dependencies.

Let’s not ignore that dependencies are far more common in JS than any of those other languages. My Go or Python projects generally only include a handful of external packages. Node projects on the other hand…

My requirements.txt does tend to be shorter than package.json, but not by a massive amount.

Hum... You should check your JavaScript numbers again.

I have never seen a project that uses npm and has only dozens of dependencies. Normal numbers are in the 10s of thousands (including different versions of some deps).

So be more selective with your dependencies then. Next.js is usually a mistake.

Some of us have been doing this for years or decades, including for our desktop OS.

Gentoo graybeards know.

Shouldn't you also restrict version number for a package not just the latest?

For smaller shops (by small I mean <1,000 employees) this isn't even tenable. We (engineering team of about 10 people) mitigate what we can via tooling and cooldown periods/minimum release age. This will work as long as these malicious packages remain reasonably detectable. I think that's the proper balance, because we can adjust the # of days we are willing to risk against the SOTA of detection tooling.

Reply on news.ycombinator.com