10 ms·

This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to

by Meneth 1y ago

This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can be added, but even then added only by the distro maintainer, NOT by the package developers. This is where the audits happen. NPM, Python, Rust, Go, Ruby all suffer from this problem, because they have centralized and open package repositories.

Aeolun 1y ago
> suffer from this problem Benefit from this feature.
weinzierl 1y ago
In Rust we have cargo vet, where we share these audits and use them in an automated fashion. Companies like Google and Mozilla contribute their audits.
- quotemstr 1y ago
  And it's a great idea, similar thematically to certificate transparency
- gedy 1y ago
  It's too bad MS doesn't own npm, and/or GitHub repositories. Wait
  - LikesPwsh 1y ago
    Nuget, Powershell gallery, the marketplaces for VSCode/VS/AZDo and the Microsoft Store too. Probably another twenty. They collect package managers like funko pops. I'm not quite sure about the goal. Maybe some more C# dev kit style rug-pulls where the ecosystem is nominally open-source but MS own the development and distribution so nobody would bother to compete.
    - lovich 1y ago
      I took those acquisitions and a few others like LinkedIn and all the visual studio versions as a sign that Microsoft is trying to own the software engineer career as a domain.
- pabs3 1y ago
  I wish cargo went with crev instead, that has a much better model for distributed code audits. https://github.com/crev-dev/ https://github.com/crev-dev/
- oneshtein 1y ago
  How to backport security fixes to vetted packages?
rixed 1y ago
Exactly, in a way Debian (or any other distro) is an extended standard library.
SkiFire13 1y ago
> Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Unfortunately most people don't want old software that doesn't support newer hardware so most people don't end up using Debian stable.
- bpt3 1y ago
  What hardware isn't supported by Debian stable that is supported by unstable? Or is this just a "don't use Linux" gripe?
  - BoredPositron 1y ago
    I haven't had much problems prior but Blackwell support was really buggy for the first two weeks.
- lenerdenator 1y ago
  It'd be interesting to see how much of the world runs on Debian containers, where most of the whole "it doesn't support my insert consumer hardware here" argument is completely moot.
- veber-alex 1y ago
  I don't know why you went with hardware. Most people don't want old software because they don't want old software. They want latest features, fixes and performance improvements.
- nzeid 1y ago
  Enable the Backport sources. The recent kernels there have supported all my modern personal devices.
- dmitrygr 1y ago
  > Unfortunately most people don't want old software "old" is a strange way to spell "new, unstable, and wormed". I want old software. Very little new features are added to most things i care about, mostly it is just bloat, AI slop, and monthly subscription shakedowns being added to software today.
paulddraper 1y ago
Go’s package repository is just GitHub. At the end of the day, it’s all a URL. You’re asking for a blessed set of URLs. You’d have to convince someone to spend time maintaining that.
- Maskawanian 1y ago
  Golang at least gives you the option to easily vendor-ize packages to your local repository. Given what has happened here, maybe we should start doing this more!
  - paulddraper 1y ago
    npm has always downloaded to the current directory.
    - Maskawanian 1y ago
      That isn't the same as vendor-izing unless you are committing node_modules to your VCS, which would be insane.
  - kelnos 1y ago
    This doesn't really help you. I assume Go records the sha1 hash of the commit it grabs, so it doesn't really matter if you vendor it, or download it every time. The problem comes when you want to upgrade your dependencies. How do you know that they are trustworthy on first use?
    - cyberax 1y ago
      Go uses the hash of the source code, not the commit ID. So there's no difference between vendoring and using the central repo.
- mdaniel 1y ago
  As hair splitting, that's actually not true: Go's package manager is just version control of which GitHub is currently the most popular hosting. And it also allows redirecting to your own version control via `go mod edit -replace` which leaves the sourcecode reference to GitHub intact, but will install it from wherever you like
hombre_fatal 1y ago
The problem with your idea is that you need to find the person who wants to do all this auditing of every version of Node/Python/Ruby libraries.
- lillecarl 1y ago
  I believe good centralized infrastructure for this would be a good start. It could be "gamified" and reviewers could earn reputation for reviewing packages, common packages would be reviewed all the time. Kinda like Stackoverflow for reviews, with optional identification and such. And honestly an LLM can strap a "probably good" badge on things with cheap batch inference.
  - pabs3 1y ago
    Decentralised auditing is what is needed. https://github.com/crev-dev/ https://github.com/crev-dev/
btown 1y ago
I'd like to think there are ways to do this and keep things decentralized. Things like: Once a package has more than [threshold] daily downloads for an extended period of time, it requires 2FA re-auth/step-up on two separate human-controlled accounts to approve any further code updates. Or something like: for these popular packages, only a select list of automated build systems with reproducible builds can push directly to NPM, which would mean that any malware injector would need to first compromise the source code repository. Which, to be fair, wouldn't necessarily have stopped this worm from propagating entirely, but would have slowed its progress considerably. This isn't a "sacrifice all of NPM's DX and decentralization" question. This is "a marginally more manual DX only when you're at a scale where you should be release-managing anyways."
- noodlesUK 1y ago
  I think that we should impose webauthn 2fa on all npm accounts as the only acceptable auth method if you have e.g., more than 1 million total downloads. Someone could pony up the cash to send out a few thousand yubikeys for this and we'd all be a lot safer.
  - thewebguyd 1y ago
    Why even put a package download count on it? Just require it for everything submitted to NPM. It's not hard.
    - ronsor 1y ago
      Because then it's extra hassle and expense for new developers to publish a package, and we're trying to keep things decentralized.
      - thewebguyd 1y ago
        It's already centralized by virtue of using and relying on NPM as the registry. If we want decentralized package management for node/javascript, you need to dump NPM - why not something like Go's system which is actually decentralized? There is no package repository/registry, it's all location based imports.
stinos 1y ago
security updates and bugfixes only Just wondering: while this is less of an attack surface, it's still a surface?
Yasuraka 1y ago
> NPM, Python, Rust, Go, Ruby all suffer from this problem, because they have centralized and open package repositories Can you point me to Go's centralized package repository?
- ForHackernews 1y ago
  https://github.com/ https://github.com/
  - Yasuraka 1y ago
    git isn't centralized nor a package repository For what it's worth, our code is on GitLab
    - ForHackernews 1y ago
      Github is a centralized repository where the overwhelming majority of Go libraries are hosted.
      - Yasuraka 1y ago
        So GitHub is every single programming language's centralized package repository? Then what's the difference between git and npm, cargo, pypi, mvn et al?
        ForHackernews 1y ago
        Git != Github. In practice, little difference between Go's use of Github and Python's use of PyPI. Someone at Microsoft with root access could compromise everyone.
        Yasuraka 1y ago
        > Git != Github That's why I'm putting emphasis on it, because to Go it is. And to languages that actually have centralized package repositories it isn't. There is a difference between code and packages and Go simply does not have the latter (in the traditional sense - what Go calls a package is a collection of source files in the same directory that are compiled together within a module (a module is a collection of packages (again, code) that are released, versioned, and distributed together. Modules may be downloaded directly from version control repositories or via proxy servers)). To the other languages mentioned above, packages may have binaries, metadata and special script hooks. There is a package manager like pip , cargo or npm and if you want to install one, you won't have to specify a URL because there is a canonical domain to go to. Go just knows code and it'll use git, hg or even svn. And if you want to claim that lots of open-source code being on GitHub makes it special, then > GitHub is every single programming language's centralized package repository and > Someone at Microsoft with root access could compromise every user of every single programming language
rlpb 1y ago
There is another related growing problem in my recent observation. As a Debian Developer, when I try to audit upstream changes before pulling them in to Debian, I find a huge amount of noise from tooling, mostly pointless. This makes it very difficult to validate the actual changes being made. For example, an upstream bumps a version of a lint tool and/or changes style across the board. Often these are labelled "chore". While I agree it's nice to have consistent style, in some projects it seems to be the majority of the changes between releases. Due to the difficulty in auditing this, I consider this part of the software supply chain problem and something to be discouraged. Unless there's actually reason to change code (eg. some genuine refactoring a human thinks is actually needed, a bug fix or new feature, a tool exposed a real bug, or at least some identifiable issue that might turn into a bug), it should be left alone.
- kirici 1y ago
  I'm using difftastic, it cuts down a whole lot of the noise https://difftastic.wilfred.me.uk/ https://difftastic.wilfred.me.uk/
  - rlpb 1y ago
    This looks good! Unfortunately it looks like it also suffers from exactly the same software supply chain problem that we need to avoid in the first place: https://github.com/Wilfred/difftastic/blob/master/Cargo.lock https://github.com/Wilfred/difftastic/blob/master/Cargo.lock Edit: also, consider how much of https://github.com/Wilfred/difftastic/commits/master/ https://github.com/Wilfred/difftastic/commits/master/ is just noise in itself. 15k commits for a project that appears to only be about four years old.
    - weinzierl 1y ago
      "exactly the same software supply chain problem" While the crates ecosystem is certainly not immune to supply chain attacks this over generalization is not justified. There are several features that make crates.io more robust than npm. One of them is that vulnerable versions can be yanked without human intervention. Desperate comments from maintainers like this one[1] from just a few days ago would not happen with crates.io. There are also features not provided by crates.io that make the situation better. For example you could very easily clone the repo and run cargo vet to check how many of the packages had human audits. I'd done it if I was on a computer, but a quick glance at the Cargo.lock file makes me confident that you'd get a significant number. [1] https://news.ycombinator.com/item?id=45170687 https://news.ycombinator.com/item?id=45170687
silverwind 1y ago
So, who is going to audit the thousands of new packages/versions that are published to npm every day? It only works for Debian because they hand-pick popular software.
- jonhohle 1y ago
  Maybe NPM should hand pick popular packages and we should get away from this idea of every platform should always let everyone publish. Curation is expensive, but it may be worthwhile for mature platforms.
- whizzter 1y ago
  This is maybe where we could start getting into money into the opensource ecosystems. One idea I've had is that publishing is open as today, but security firms could offer audit signatures. So a company might pay security firms and only accept updates to packages that have been audited by by 1,2,3 or more of their paid services. Thus money would be paid in the open to have eyes on changes for popular packages and avoid the problem of that weird lone maintainer in northern Finland being attacked by the Chinese state.
- dvh 1y ago
  Errr, you! If you brought the dependency, it is now your job to maintain it and diff every update for backdoor.
f33d5173 1y ago
You can use debian's version of your npm packages if you'd like. The issues you're likely to run into are: some libraries won't be packaged period by debian; those that are might be on unacceptably old versions. You can work around these issues by vendoring dependencies that aren't in your distro's repo, ie copying a particular version into your own source control, manually keeping up with security updates. This is, to my knowledge, what large tech companies do. Other companies that don't are either taking a known risk with regards to vulnerabilities, or are ignorant. Ignorance is very common in this industry.
LtWorf 1y ago
> The general solution is to do what Debian does. If you ask these people, distributions are terrible and need to die. Python even removed PGP signatures from Pypi because now attestation happens by microsoft signing your build on the github CI and uploading it directly to pypi with a never expiring token. And that's secure, as opposed to the developer uploading locally from their machine. In theory it's secure because you see what's going in there on git, but in practice github actions are completely insecure so malware has been uploaded this way already.
ncruces 1y ago
This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them, thereby giving hundreds of third-parties access to their build (or worse) execution environments. Adding friction to the sharing of code doesn't absolve developers from their decision to blindly trust a ridiculous amount of third-parties.
- zwnow 1y ago
  Unfortunately that's almost the whole industry. Every software project I've seen has an uncountable amount of dependencies. No matter if npm, cargo, go packages, whatever you name.
  - AnonymousPlanet 1y ago
    Every place I ever worked at made sure to curate the dependencies for their main projects. Heck, in some cases that was even necessary for certifications. Web dev might be a wild west, but as soon as your software is installed on prem by hundreds or thousands of paying customers the stakes change.
    - zwnow 1y ago
      Curating dependencies won't prevent all supply chain attacks though
  - jen20 1y ago
    Zero-external-dependency Go apps are far more feasible than Rust or Node, simply because of the size and quality of the standard library.
    - ncruces 1y ago
      Just the other day someone argued with me that it was reasonable for Limbo (the SQLite Rust rewrite) to have 3135 dependencies (of those, 1313 Rust dependencies). https://github.com/tursodatabase/turso/network/dependencies https://github.com/tursodatabase/turso/network/dependencies
neutrinobro 1y ago
The lack of an easy method to automatically pull in and manage dependencies in C/C++ is starting to look a lot more like a feature than a bug now.
- edtech_dev 1y ago
  Author of Odin is also against adding a package manager: https://www.gingerbill.org/article/2025/09/08/package-managers-are-evil/ https://www.gingerbill.org/article/2025/09/08/package-manage...
- morning-coffee 1y ago
  But there's so much UB in C++ that can be exploited that I doubt attackers lament the lack of a module system to target. ;)
cycomanic 1y ago
I've been arguing a couple of times that the 2 main reasons people want package management in languages are 1. Using an operating system with no package management 2. Poor developer discipline, i.e. developers always trying to use the latest version of a package. So now we have lots of poorly implemented language package managers, docker containers on top being used as another package management layer (even though that's not their primary purpose but many people use the like that) and the security implications of pulling in lots of random dependencies without any audit. Developing towards a stable base like Debian would not be a pancea, but alliviate the problems by at least placing another audit layer in between.
- IshKebab 1y ago
  Nope. It's because: 1. You don't want to tie your software to the OS. Most people want their software to be cross-platform. Much better to have a language-specific package manager because I'm using the same language on every OS. And when I say "OS" here, I really mean OS or Linux distro, because Linux doesn't have one package manager. 2. OS package managers (where they even exist), have too high a bar of entry. Not only do you have to make a load of different packages for different OSes and distros, but you have to convince all of them to accept them. Waaay too much work for all but the largest projects. You're probably going to say "Good! It would solve this problem!", but I don't think the solution to package security is to just make it so annoying nobody bothers. We can do better than that.
  - cycomanic 1y ago
    I actually agree in the context of user software people often want the latest and that Windows and OS don't have proper package management is an issue. However we are talking in the context of NPM packages which by the vast majority would be running inside a container on some server. So how could that software not use a stable Debian base for example. And arguing that package management is to complicated is a bit ridiculous considering how many workloads are running in docker containers which I'd argue are significantly more complex
- cortesoft 1y ago
arp242 1y ago
You're overestimating the amount of auditing these distros do for the average package; in reality there is very little. The reason these compromised packages typically don't make it in to e.g. Debian is because this all tends to be discovered quite quickly, before the package maintainer has a chance to update it.
rpcope1 1y ago
Yeah, after seeing all of the crazy stuff that has been occurring around supply chain attacks, and realizing that latest Debian stable (despite the memes) already has a lot of decent relatively up-to-date packages for Python, it's often easier to default to just building against what Debian provides.
cortesoft 1y ago
In practice, my experience is that this ends up with only old versions of things in the stable package repos. So many times I run into a bug, and then find out that the bug has been fixed in a newer version but it isn't updated in the stable repo. So now you end up pulling an update out of band, and you are in the same boat as before. I don't know how you avoid this problem
cuillevel3 1y ago
Distros are struggling with the amount of packages they have to maintain and update regularly. That's one of the main reasons why languages built their own ecosystems in the first place. It became popular with CPAN and Maven and took off with Ruby gems. Linux distros can't even provide all the apps users want, that's why freshmeat existed and we have linuxbrew, flatpak, Ubuntu multiverse, PPA, third party Debian repositories, the openSUSE Buildservice, the AUR, ... There is no community that has the capacity to audit and support multiple branches of libraries.
orblivion 1y ago
For python I use Debian packages wherever possible. What I need is in there usually. I might even say almost always.
pabs3 1y ago
To be clear, Debian does not audit code like you might be suggesting they do. There are checks for licensing, source code being missing, build reproducibility, tests and other things. There is some static analysis with lintian, but not systematically at the source code level with tools like cppcheck or rust-analyzer or similar. Auditing the entirety of the code for security issues just isn't feasible for package maintainers. Malware might be noticed while looking for other issues, that isn't guaranteed though, the XZ backdoor wasn't picked up by Debian. https://lintian.debian.org/ https://lintian.debian.org/
pxc 1y ago
Right. Like NPM, Debian also supports post-install hooks for its packages. Not great (ask Michael Stapelberg)! But this is still a bit better than the NPM situation because at least the people writing the hooks aren't the people writing the applications, and there's some standards for what is considered sane to do with such hooks, and some communal auditing of those hooks' behavior. Linux distros could still stand to improve here in a bunch of ways, and it seems that a well-designed package ecosystem truly doesn't need such hooks at the level of the package manager at all. But this kind of auditing is one of the useful functions of downstream software distros for sure.
ExoticPearTree 1y ago
> The general solution is to do what Debian does. The problem with this approach is that frameworks tend to "expire" pretty quickly and you can't run anything for too long on Debian until the framework is obsolete. What I mean by obsolete is Debian 13 ships with Golang 1.24, A year from now it's gonna be Golang 1.26 - that is not being made available in trixie. So you have to find an alternative source for the latest golang deb. Same with PHP, Python etc. If you run them for 3 years with no updated just some security fixes here and there, you're gonna wake up in a world of hurt when the next stable release comes out and you have to do en-masse updates that will most likely require huge refactoring because syntax, library changes and so on. And Javascript is a problem all by itself where versions come up every few months and packages are updated weekly or monthly. You can't run any "modern" app with old packages unless you accept all the bugs or you put in the work and fix them. I am super interested in a solution for this that provides some security for packages pushed to NPM (the most problematic repository). And for distributions to have a healthy updated ecosystem of packages so you don't get stuck who knows for how long on an old version of some package. And back to Debian, trixie ships with nginx 1.26.3-3+deb13u1. Why can't they continuously ship the latest stable version if they don't want to use the mainline one?
aljarry 1y ago
NX NPM attack (at least the previous wave which targetted tinycolor) relied on running post-install scripts. Go tooling does not give you ways to run post-install scripts, which is much more reasonable approach.
fennecfoxy 1y ago
Pretty unfeasible with the variety of packages/ecosystems that get created. You'd either ending up requiring a LOT of dev time looking over packages on the maintainer end, or basically having no packages people need to use in your repository. Finding the balance of that seems to me like it'd be incredibly difficult.

by Meneth 1y ago

Aeolun 1y ago

> suffer from this problem Benefit from this feature.

weinzierl 1y ago

In Rust we have cargo vet, where we share these audits and use them in an automated fashion. Companies like Google and Mozilla contribute their audits.

quotemstr 1y ago
And it's a great idea, similar thematically to certificate transparency
gedy 1y ago
It's too bad MS doesn't own npm, and/or GitHub repositories. Wait
- LikesPwsh 1y ago
  Nuget, Powershell gallery, the marketplaces for VSCode/VS/AZDo and the Microsoft Store too. Probably another twenty. They collect package managers like funko pops. I'm not quite sure about the goal. Maybe some more C# dev kit style rug-pulls where the ecosystem is nominally open-source but MS own the development and distribution so nobody would bother to compete.
  - lovich 1y ago
    I took those acquisitions and a few others like LinkedIn and all the visual studio versions as a sign that Microsoft is trying to own the software engineer career as a domain.
pabs3 1y ago
I wish cargo went with crev instead, that has a much better model for distributed code audits. https://github.com/crev-dev/ https://github.com/crev-dev/
oneshtein 1y ago
How to backport security fixes to vetted packages?

rixed 1y ago

Exactly, in a way Debian (or any other distro) is an extended standard library.

SkiFire13 1y ago

> Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Unfortunately most people don't want old software that doesn't support newer hardware so most people don't end up using Debian stable.

bpt3 1y ago
What hardware isn't supported by Debian stable that is supported by unstable? Or is this just a "don't use Linux" gripe?
- BoredPositron 1y ago
  I haven't had much problems prior but Blackwell support was really buggy for the first two weeks.
lenerdenator 1y ago
It'd be interesting to see how much of the world runs on Debian containers, where most of the whole "it doesn't support my insert consumer hardware here" argument is completely moot.
veber-alex 1y ago
I don't know why you went with hardware. Most people don't want old software because they don't want old software. They want latest features, fixes and performance improvements.
nzeid 1y ago
Enable the Backport sources. The recent kernels there have supported all my modern personal devices.
dmitrygr 1y ago
> Unfortunately most people don't want old software "old" is a strange way to spell "new, unstable, and wormed". I want old software. Very little new features are added to most things i care about, mostly it is just bloat, AI slop, and monthly subscription shakedowns being added to software today.

paulddraper 1y ago

Go’s package repository is just GitHub. At the end of the day, it’s all a URL. You’re asking for a blessed set of URLs. You’d have to convince someone to spend time maintaining that.

Maskawanian 1y ago
Golang at least gives you the option to easily vendor-ize packages to your local repository. Given what has happened here, maybe we should start doing this more!
- paulddraper 1y ago
  npm has always downloaded to the current directory.
  - Maskawanian 1y ago
    That isn't the same as vendor-izing unless you are committing node_modules to your VCS, which would be insane.
- kelnos 1y ago
  This doesn't really help you. I assume Go records the sha1 hash of the commit it grabs, so it doesn't really matter if you vendor it, or download it every time. The problem comes when you want to upgrade your dependencies. How do you know that they are trustworthy on first use?
  - cyberax 1y ago
    Go uses the hash of the source code, not the commit ID. So there's no difference between vendoring and using the central repo.
mdaniel 1y ago
As hair splitting, that's actually not true: Go's package manager is just version control of which GitHub is currently the most popular hosting. And it also allows redirecting to your own version control via `go mod edit -replace` which leaves the sourcecode reference to GitHub intact, but will install it from wherever you like

hombre_fatal 1y ago

The problem with your idea is that you need to find the person who wants to do all this auditing of every version of Node/Python/Ruby libraries.

lillecarl 1y ago
I believe good centralized infrastructure for this would be a good start. It could be "gamified" and reviewers could earn reputation for reviewing packages, common packages would be reviewed all the time. Kinda like Stackoverflow for reviews, with optional identification and such. And honestly an LLM can strap a "probably good" badge on things with cheap batch inference.
- pabs3 1y ago
  Decentralised auditing is what is needed. https://github.com/crev-dev/ https://github.com/crev-dev/

btown 1y ago

I'd like to think there are ways to do this and keep things decentralized. Things like: Once a package has more than [threshold] daily downloads for an extended period of time, it requires 2FA re-auth/step-up on two separate human-controlled accounts to approve any further code updates. Or something like: for these popular packages, only a select list of automated build systems with reproducible builds can push directly to NPM, which would mean that any malware injector would need to first compromise the source code repository. Which, to be fair, wouldn't necessarily have stopped this worm from propagating entirely, but would have slowed its progress considerably. This isn't a "sacrifice all of NPM's DX and decentralization" question. This is "a marginally more manual DX only when you're at a scale where you should be release-managing anyways."

noodlesUK 1y ago
I think that we should impose webauthn 2fa on all npm accounts as the only acceptable auth method if you have e.g., more than 1 million total downloads. Someone could pony up the cash to send out a few thousand yubikeys for this and we'd all be a lot safer.
- thewebguyd 1y ago
  Why even put a package download count on it? Just require it for everything submitted to NPM. It's not hard.
  - ronsor 1y ago
    Because then it's extra hassle and expense for new developers to publish a package, and we're trying to keep things decentralized.
    - thewebguyd 1y ago
      It's already centralized by virtue of using and relying on NPM as the registry. If we want decentralized package management for node/javascript, you need to dump NPM - why not something like Go's system which is actually decentralized? There is no package repository/registry, it's all location based imports.

stinos 1y ago

security updates and bugfixes only Just wondering: while this is less of an attack surface, it's still a surface?

Yasuraka 1y ago

> NPM, Python, Rust, Go, Ruby all suffer from this problem, because they have centralized and open package repositories Can you point me to Go's centralized package repository?

ForHackernews 1y ago
https://github.com/ https://github.com/
- Yasuraka 1y ago
  git isn't centralized nor a package repository For what it's worth, our code is on GitLab
  - ForHackernews 1y ago
    Github is a centralized repository where the overwhelming majority of Go libraries are hosted.
    - Yasuraka 1y ago
      So GitHub is every single programming language's centralized package repository? Then what's the difference between git and npm, cargo, pypi, mvn et al?
      - ForHackernews 1y ago
        Git != Github. In practice, little difference between Go's use of Github and Python's use of PyPI. Someone at Microsoft with root access could compromise everyone.
        Yasuraka 1y ago
        > Git != Github That's why I'm putting emphasis on it, because to Go it is. And to languages that actually have centralized package repositories it isn't. There is a difference between code and packages and Go simply does not have the latter (in the traditional sense - what Go calls a package is a collection of source files in the same directory that are compiled together within a module (a module is a collection of packages (again, code) that are released, versioned, and distributed together. Modules may be downloaded directly from version control repositories or via proxy servers)). To the other languages mentioned above, packages may have binaries, metadata and special script hooks. There is a package manager like pip , cargo or npm and if you want to install one, you won't have to specify a URL because there is a canonical domain to go to. Go just knows code and it'll use git, hg or even svn. And if you want to claim that lots of open-source code being on GitHub makes it special, then > GitHub is every single programming language's centralized package repository and > Someone at Microsoft with root access could compromise every user of every single programming language

rlpb 1y ago

There is another related growing problem in my recent observation. As a Debian Developer, when I try to audit upstream changes before pulling them in to Debian, I find a huge amount of noise from tooling, mostly pointless. This makes it very difficult to validate the actual changes being made. For example, an upstream bumps a version of a lint tool and/or changes style across the board. Often these are labelled "chore". While I agree it's nice to have consistent style, in some projects it seems to be the majority of the changes between releases. Due to the difficulty in auditing this, I consider this part of the software supply chain problem and something to be discouraged. Unless there's actually reason to change code (eg. some genuine refactoring a human thinks is actually needed, a bug fix or new feature, a tool exposed a real bug, or at least some identifiable issue that might turn into a bug), it should be left alone.

kirici 1y ago
I'm using difftastic, it cuts down a whole lot of the noise https://difftastic.wilfred.me.uk/ https://difftastic.wilfred.me.uk/
- rlpb 1y ago
  This looks good! Unfortunately it looks like it also suffers from exactly the same software supply chain problem that we need to avoid in the first place: https://github.com/Wilfred/difftastic/blob/master/Cargo.lock https://github.com/Wilfred/difftastic/blob/master/Cargo.lock Edit: also, consider how much of https://github.com/Wilfred/difftastic/commits/master/ https://github.com/Wilfred/difftastic/commits/master/ is just noise in itself. 15k commits for a project that appears to only be about four years old.
  - weinzierl 1y ago
    "exactly the same software supply chain problem" While the crates ecosystem is certainly not immune to supply chain attacks this over generalization is not justified. There are several features that make crates.io more robust than npm. One of them is that vulnerable versions can be yanked without human intervention. Desperate comments from maintainers like this one[1] from just a few days ago would not happen with crates.io. There are also features not provided by crates.io that make the situation better. For example you could very easily clone the repo and run cargo vet to check how many of the packages had human audits. I'd done it if I was on a computer, but a quick glance at the Cargo.lock file makes me confident that you'd get a significant number. [1] https://news.ycombinator.com/item?id=45170687 https://news.ycombinator.com/item?id=45170687

silverwind 1y ago

So, who is going to audit the thousands of new packages/versions that are published to npm every day? It only works for Debian because they hand-pick popular software.

jonhohle 1y ago
Maybe NPM should hand pick popular packages and we should get away from this idea of every platform should always let everyone publish. Curation is expensive, but it may be worthwhile for mature platforms.
whizzter 1y ago
This is maybe where we could start getting into money into the opensource ecosystems. One idea I've had is that publishing is open as today, but security firms could offer audit signatures. So a company might pay security firms and only accept updates to packages that have been audited by by 1,2,3 or more of their paid services. Thus money would be paid in the open to have eyes on changes for popular packages and avoid the problem of that weird lone maintainer in northern Finland being attacked by the Chinese state.
dvh 1y ago
Errr, you! If you brought the dependency, it is now your job to maintain it and diff every update for backdoor.

f33d5173 1y ago

You can use debian's version of your npm packages if you'd like. The issues you're likely to run into are: some libraries won't be packaged period by debian; those that are might be on unacceptably old versions. You can work around these issues by vendoring dependencies that aren't in your distro's repo, ie copying a particular version into your own source control, manually keeping up with security updates. This is, to my knowledge, what large tech companies do. Other companies that don't are either taking a known risk with regards to vulnerabilities, or are ignorant. Ignorance is very common in this industry.

LtWorf 1y ago

> The general solution is to do what Debian does. If you ask these people, distributions are terrible and need to die. Python even removed PGP signatures from Pypi because now attestation happens by microsoft signing your build on the github CI and uploading it directly to pypi with a never expiring token. And that's secure, as opposed to the developer uploading locally from their machine. In theory it's secure because you see what's going in there on git, but in practice github actions are completely insecure so malware has been uploaded this way already.

ncruces 1y ago

This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them, thereby giving hundreds of third-parties access to their build (or worse) execution environments. Adding friction to the sharing of code doesn't absolve developers from their decision to blindly trust a ridiculous amount of third-parties.

zwnow 1y ago
Unfortunately that's almost the whole industry. Every software project I've seen has an uncountable amount of dependencies. No matter if npm, cargo, go packages, whatever you name.
- AnonymousPlanet 1y ago
  Every place I ever worked at made sure to curate the dependencies for their main projects. Heck, in some cases that was even necessary for certifications. Web dev might be a wild west, but as soon as your software is installed on prem by hundreds or thousands of paying customers the stakes change.
  - zwnow 1y ago
    Curating dependencies won't prevent all supply chain attacks though
- jen20 1y ago
  Zero-external-dependency Go apps are far more feasible than Rust or Node, simply because of the size and quality of the standard library.
  - ncruces 1y ago
    Just the other day someone argued with me that it was reasonable for Limbo (the SQLite Rust rewrite) to have 3135 dependencies (of those, 1313 Rust dependencies). https://github.com/tursodatabase/turso/network/dependencies https://github.com/tursodatabase/turso/network/dependencies

neutrinobro 1y ago

The lack of an easy method to automatically pull in and manage dependencies in C/C++ is starting to look a lot more like a feature than a bug now.

edtech_dev 1y ago
Author of Odin is also against adding a package manager: https://www.gingerbill.org/article/2025/09/08/package-managers-are-evil/ https://www.gingerbill.org/article/2025/09/08/package-manage...
morning-coffee 1y ago
But there's so much UB in C++ that can be exploited that I doubt attackers lament the lack of a module system to target. ;)

cycomanic 1y ago

I've been arguing a couple of times that the 2 main reasons people want package management in languages are 1. Using an operating system with no package management 2. Poor developer discipline, i.e. developers always trying to use the latest version of a package. So now we have lots of poorly implemented language package managers, docker containers on top being used as another package management layer (even though that's not their primary purpose but many people use the like that) and the security implications of pulling in lots of random dependencies without any audit. Developing towards a stable base like Debian would not be a pancea, but alliviate the problems by at least placing another audit layer in between.

IshKebab 1y ago
Nope. It's because: 1. You don't want to tie your software to the OS. Most people want their software to be cross-platform. Much better to have a language-specific package manager because I'm using the same language on every OS. And when I say "OS" here, I really mean OS or Linux distro, because Linux doesn't have one package manager. 2. OS package managers (where they even exist), have too high a bar of entry. Not only do you have to make a load of different packages for different OSes and distros, but you have to convince all of them to accept them. Waaay too much work for all but the largest projects. You're probably going to say "Good! It would solve this problem!", but I don't think the solution to package security is to just make it so annoying nobody bothers. We can do better than that.
- cycomanic 1y ago
  I actually agree in the context of user software people often want the latest and that Windows and OS don't have proper package management is an issue. However we are talking in the context of NPM packages which by the vast majority would be running inside a container on some server. So how could that software not use a stable Debian base for example. And arguing that package management is to complicated is a bit ridiculous considering how many workloads are running in docker containers which I'd argue are significantly more complex
cortesoft 1y ago

arp242 1y ago

You're overestimating the amount of auditing these distros do for the average package; in reality there is very little. The reason these compromised packages typically don't make it in to e.g. Debian is because this all tends to be discovered quite quickly, before the package maintainer has a chance to update it.

rpcope1 1y ago

Yeah, after seeing all of the crazy stuff that has been occurring around supply chain attacks, and realizing that latest Debian stable (despite the memes) already has a lot of decent relatively up-to-date packages for Python, it's often easier to default to just building against what Debian provides.

cortesoft 1y ago

In practice, my experience is that this ends up with only old versions of things in the stable package repos. So many times I run into a bug, and then find out that the bug has been fixed in a newer version but it isn't updated in the stable repo. So now you end up pulling an update out of band, and you are in the same boat as before. I don't know how you avoid this problem

cuillevel3 1y ago

Distros are struggling with the amount of packages they have to maintain and update regularly. That's one of the main reasons why languages built their own ecosystems in the first place. It became popular with CPAN and Maven and took off with Ruby gems. Linux distros can't even provide all the apps users want, that's why freshmeat existed and we have linuxbrew, flatpak, Ubuntu multiverse, PPA, third party Debian repositories, the openSUSE Buildservice, the AUR, ... There is no community that has the capacity to audit and support multiple branches of libraries.

orblivion 1y ago

For python I use Debian packages wherever possible. What I need is in there usually. I might even say almost always.

pabs3 1y ago

To be clear, Debian does not audit code like you might be suggesting they do. There are checks for licensing, source code being missing, build reproducibility, tests and other things. There is some static analysis with lintian, but not systematically at the source code level with tools like cppcheck or rust-analyzer or similar. Auditing the entirety of the code for security issues just isn't feasible for package maintainers. Malware might be noticed while looking for other issues, that isn't guaranteed though, the XZ backdoor wasn't picked up by Debian. https://lintian.debian.org/ https://lintian.debian.org/

pxc 1y ago

Right. Like NPM, Debian also supports post-install hooks for its packages. Not great (ask Michael Stapelberg)! But this is still a bit better than the NPM situation because at least the people writing the hooks aren't the people writing the applications, and there's some standards for what is considered sane to do with such hooks, and some communal auditing of those hooks' behavior. Linux distros could still stand to improve here in a bunch of ways, and it seems that a well-designed package ecosystem truly doesn't need such hooks at the level of the package manager at all. But this kind of auditing is one of the useful functions of downstream software distros for sure.

ExoticPearTree 1y ago

> The general solution is to do what Debian does. The problem with this approach is that frameworks tend to "expire" pretty quickly and you can't run anything for too long on Debian until the framework is obsolete. What I mean by obsolete is Debian 13 ships with Golang 1.24, A year from now it's gonna be Golang 1.26 - that is not being made available in trixie. So you have to find an alternative source for the latest golang deb. Same with PHP, Python etc. If you run them for 3 years with no updated just some security fixes here and there, you're gonna wake up in a world of hurt when the next stable release comes out and you have to do en-masse updates that will most likely require huge refactoring because syntax, library changes and so on. And Javascript is a problem all by itself where versions come up every few months and packages are updated weekly or monthly. You can't run any "modern" app with old packages unless you accept all the bugs or you put in the work and fix them. I am super interested in a solution for this that provides some security for packages pushed to NPM (the most problematic repository). And for distributions to have a healthy updated ecosystem of packages so you don't get stuck who knows for how long on an old version of some package. And back to Debian, trixie ships with nginx 1.26.3-3+deb13u1. Why can't they continuously ship the latest stable version if they don't want to use the mainline one?

aljarry 1y ago

NX NPM attack (at least the previous wave which targetted tinycolor) relied on running post-install scripts. Go tooling does not give you ways to run post-install scripts, which is much more reasonable approach.

fennecfoxy 1y ago

Pretty unfeasible with the variety of packages/ecosystems that get created. You'd either ending up requiring a LOT of dev time looking over packages on the maintainer end, or basically having no packages people need to use in your repository. Finding the balance of that seems to me like it'd be incredibly difficult.