Linux distribution model

Arguments that curated package repositories like Debian's approach of staging and human review could apply to npm ecosystem

To address the increasing frequency of supply chain attacks, many argue that modern ecosystems like npm should abandon their "wild west" publishing model in favor of the curated, human-reviewed approach used by Linux distributions. Proponents suggest implementing tiered "rings" of trust, mandatory staging periods, and M-of-N auditor sign-offs to ensure that critical dependencies are pulled into a repository through rigorous oversight rather than pushed on a whim by a single developer. While some worry that the sheer volume of packages makes this model difficult to scale, others envision a "code-review-as-a-service" economy where users pay for vetted, stable bundles similar to the historic reliability of CPAN or Debian. Ultimately, the consensus leans toward moving accountability away from individual consumers and into a centralized, pull-based distribution layer that prioritizes long-term security over the speed of unverified releases.

View on HN · Topics

Batteries included systems are still susceptible to supply chain attacks, they just move slower so it’s not as attractive of a target.

I think packages of a certain size need to be held to higher standards by the repositories.
Multiple users should have to approve changes. Maybe enforced scans (though with trivy’s recent compromise that wont be likely any time soon)

Basically anything besides lone developer can decide to send something out on a whim that will run on millions of machines.

View on HN · Topics

or you don't use a package manager where anyone can just publish a package (i.e. use your system package manager). There is still some risk, but it is much smaller. Like, if xz were distributed by PyPI or NPM, everyone would have been pwned, but instead it was (barely) found.

It's true that system repos doesn't include everything, but you can create your own repositories if you really need to for a few things. In practice Fedora/EPEL are basically sufficient for my needs. Right now I'm deploying something with yocto, which is a bit more limited in slection, but it's pretty easy to add my own packages and it at least has hashes so things don't get replaced without me noticing (to be fair, I don't know if the security practices of open-embedded recipes are as strong as Fedora...).

View on HN · Topics

it's muddying what a package is. A package, or a distro, is the people who slave and labor over packaging, reviewing, deciding on versions to ship, having policies in place, security mailing lists, release schedules, etc.

just shipping from npm crap is essentially the equivelant of running your production code base against Arch AUR pkgbuilds.

View on HN · Topics

We could have different Python package bundles: Python base. Python webdev. Python desktop.

View on HN · Topics

Not at all. We simply need M-of-N auditors to sign off on major releases of things. And the package managers need to check this (the set of auditors can be changed, same as browser PKI for https) before pulling things down.

That's the system we have in our Safebox ecosystem

View on HN · Topics

And when you actually need a super hot fix for a 0-day, you will need to revert this and keep it that way for some time to then go back to minimum age.

While this works, we stillneed a permanent solution which requires a sort of vetting process, rather than blindly letting everything through.

View on HN · Topics

Who will do the vetting process?

View on HN · Topics

I think my vetting would settle for a repo diff against the previous version, confirming the only difference was the security fix (though that doesn't cover all the bases).

View on HN · Topics

Jia Tan

View on HN · Topics

Hosting curated dependencies is a commercially valuable service. Eventually an economy arises where people pay vendors to vet packages.

View on HN · Topics

It's what linux distributions do.

View on HN · Topics

Queue appimage or other packed binary and there go your finetuned packages.

View on HN · Topics

Yes, that why those need to be 100% sandboxed by default (ideally a VM), unless they are provided by distro

View on HN · Topics

It already exists; cloudsmith

View on HN · Topics

Linux distros and BSD ports did that since the 90's. When Linux distros had barely a PM or just tarballs, Infomagic sold 4 CD full of libre software. When I had no internet at home, back in the day I bought 3 DVD's of Debian Sarge for 20 euros, about $20. A bargain, it was the price of a hard-cover best seller book.

GB's of libre software, graphical install, 2.6 kernel, KDE3 desktop, very light on my Athlon 2000 with 256MB of RAM. It was incredible compared to what you got with Windows XP and 120 Euro per seat. Nonfree software and almost empty.

And, well, if for instance I could get read only, ~16TB durable USB drive with tons of Guix packages offline (in a two yearly basis with stable releases) for $200 I would buy them in the spot.

You would say that $200 for a distro it's expensive, but for what it provides, if you are only interested in libre gaming and tools, they amount you save can be huge. I've seen people spend $400 in Steam games because of the Holyday sales...

View on HN · Topics

NPM should have a curation mechanism, via staff review or crowdsourcing, where versions of popular packages are promoted to a stable set, like linux distros do. I would only use curated versions if they had such a thing.

View on HN · Topics

The number of issues is disproportionately larger than the one for Debian.

View on HN · Topics

Debian is slower so npm is more attractive

View on HN · Topics

CPAN too, just try Hailo under Perl to test an old-fashioned chatbot based on Markov chains where very small LLM's and Hailo converge if used with the advanced training options for it. Yes, it will pull tons of dependencies, (less with cpanminus if run with 'cpanm -n Hailo'), but contrary to NPM, Pip and the like CPAN's repos are highly curated and before PHP and ubiquitoous Python Perl was used everywhere, from a sysadmin language (better than Bash/Sh for sure) to CGI, IRC bots and whatnot. How many issues did we have? Zero or near zero.

View on HN · Topics

I don't think this community of professionals is going to come around to a solution which requires marginally more effort.

If no one checks their dependencies, the solution is to centralize this responsibility at the package repository. Something like left-pad should simply not be admitted to npm. Enforce a set of stricter rules which only allow non-trivial packages maintained by someone who is clearly accountable.

Another change one could make is develop bigger standard libraries with all the utilities which are useful.
For example in Rust there are a few de facto standard packages one needs very often, which then also force you to pull in a bunch of transitive dependencies.
Those could also be part of the standard library.

This all amounts to increasing the minimal scope of useful functionality a package has to have to be admitted and increasing accountability of the people maintaining them. This obviously comes with more effort on the maintainers part, but hey maybe we could even pay them for their labor.

View on HN · Topics

I'd really like to see package managers organized around rings where a very small core of incredibly important stuff is kept in ring 0, ring 1 gets a slightly wider amount of stuff and can only depend on ring 0 dependencies and then ring 2+ is the crapware libraries that infect most ecosystems.

But maybe that's not the right fit either. The world where package managers are just open to whatever needs to die. It's no longer a safe model.

View on HN · Topics

The OS distro model is actually the right one here. Upstream authors hate it, but having a layer that's responsible for picking versions out of the ecosystem and compiling an internally consistent grouping of known mutually-compatible versions that you can subscribe to means that a lot of the random churn just falls away. Once you've got that layer, you only need to be aware of security problems in the specific versions you care about, you can specifically patch only them , and you've got a distribution channel for the fixes where it's far more feasible to say "just auto-apply anything that comes via this route".

That model effectively becomes your ring 1. Ring 0 is the stdlib and the package manager itself, and - because you would always need to be able to step outside the distribution for either freshness or "that's not been picked up by the distro yet" reasons - the ecosystem package repositories are the wild west ring 2.

In the language ecosystems I'm only aware of Quicklisp/Ultralisp and Haskell's Stackage that work like this. Everything else is effectively a rolling distro that hasn't realised that's what it is yet.

View on HN · Topics

Malicious actor KPI: affect a Ring 0 package.

View on HN · Topics

Package managers are older than some users here. From CPAN/CTAN to ports under BSD's.

Some pm's are badly maintained (Pip/NPM), while others are curated enough.

Again, if you have GNU/Linux installed, install Guix, read the Info manual on 'guix import' and just create a shell/container with 'guix shell --container' (and a manifest package created from guix import) and use any crap you need for NPM in a reproducible and isolated way. You $HOME will be safe, for sure.

View on HN · Topics

Why not just release escrow? If I try to push a new release version another developer or developers have to agree to that release. In larger projects you would expect the release to be coordinated or scheduled anyways. Effectively we're just moving "version pinning" or "version delay" one layer up the release chain.

View on HN · Topics

Or those people can (fund) separate repackaging and redistribution with more stringent and formalized review process.

Maybe not all users should pull all packages straight from what devs are pushing.

There's no reason we can't have "node package distributions" like we have Linux distributions. Maybe we should stop expecting devs and maintainers and Microsoft to take responsibility for our supply-chain.

View on HN · Topics

There are so many scanners these days these things get caught pretty quick. I think we need either npm or someone else to have a registry that only lets through packages that pass these scanners. Can even do the virustotal thing of aggregating reports by multiple scanners. NPM publishes attestation for trusted build environments. Google has oss-rebuild.

All it takes is an `npm config set` to switch registries anyways. The hard part is having a central party that is able to convince all the various security companies to collaborate rather than having dozens of different registries each from each company.

Rather than just a hard-coded delay, I think having policies on what checks must pass first makes sense with overrides for when CVEs show up.

(WIP)

View on HN · Topics

Many of the suggestions in this thread (min-release, ignore script) are defenses for the consumers.

I've been working on Proof of Resilience, a set of 4 metrics for OSS, and using that as a scoring oracle for what to fund.

Popularity metrics like downloads, stars, etc are easy to fake today with ai agents. An interesting property is that gaming these metrics produces better code, not worse.

These are the 4 metrics:

1. Build determinism - does the published artifact match a reproducible build from source?

2. Fuzzing survival - does the package survive fuzz testing?

3. Downstream stability - does it break any repos dependent on this project when pushing a release?

4. Patch velocity - how fast are fixes merged?

Here's a link to the post, still early but would appreciate any feedback.

https://hackmd.io/@carlb/proof-of-resilience

View on HN · Topics

NPM should learn from Linux distribution package managers.

Have a branch called testing, and packages stay in testing for few weeks, after which they go to stable. That is how many Linux distributions handle packages. It would have prevented many of these.

Advising every user of npm/pnpm to change their settings and set their own cooldown periods is not a real choice.

View on HN · Topics

Not all distributions work with a staging repository, and it's not really intended for this purpose either.

Besides there's always a way to immediately push a new version to stable repositories. You have to in order to deal with regressions and security fixes.

View on HN · Topics

I know not all, but Debian/Ubuntu/Fedora does, and while the intended purpose of multi-stage releases is not necessarily security but stability, it still does help up with security too. Because third parties can look and scan the dependencies while they are still not in stable.

Most of the supply chain vulnerabilities that ended up in the NPM would have been mitigated with having mandatory testing / stable branches, of course there needs to be some sort of way to skip the testing but that would be rather rare and cumbersome and audited, like it is in Linux distributions too.

View on HN · Topics

NPM is one big AUR, where anyone can submit arbitrary unverified code. The difference is that AUR is intentionally harder to use to prevent catastrophic one-line installs.

View on HN · Topics

Is a "AUR" now just how we name unaudited software repositories?

Just to note, if we're talking about Linux Distributions. There's also COPR in Fedora, OBS for OpenSUSE (and a bunch of other stuff, OBS is awesome), Ubuntu has PPAs. And I am sure there's many more similar solutions.

View on HN · Topics

Is this Jia Tan 5.0? I've lost count. You really should stop trusting packages (implicitly). Or don't. It's your funeral, not mine. See you at Jia Tan 6.0 April?

View on HN · Topics

I'd argue this has not much in common with Jia Tan apart from both being supply chain attacks, there is no malicious maintainer here, a trusted maintainer had their account taken over.

I guess the end result is the same, a malicious package pushed by an account that was thought to be trusted, but I think the Jia Tan case is worth being looked at differently than just simple account takeover.

View on HN · Topics

I have a few projects which rely on npm (and react) and every few months I have to revisit them to do an update and make sure they still build, and I am basically done with npm and the entire ecosystem at this point.

Sure, its convenient to have so much code to use for basic functionality - but the technical debt of having to maintain these projects is just too damn high.

At this point I think that, if I am forced to use javascript or node for a project, I reconsider involvement in that project. Its ecosystem is just so bonkers I can't justify the effort much longer.

There has to be some kind of "code-review-as-a-service" that can be turned on here to catch these things. Its just so unproductive, every single time .

View on HN · Topics

Other languages have package managers (perl) and there are package managers in existence that are not so vulnerable to this issue. IMO, it stems from one place: Transitive dependencies and general opaqueness of the issue.

In package managers like pacman, apt, apk,... it's easier to catch such issue. They do have postinstall scripts, but it's part of the submission to the repo, not part of the project. Whatever comes from the project is hashed, and that hash is also visible as part of the submission. That makes it a bit difficult to sneak something. You don't push a change, they pull yours.

Summarizer