Hacker News Reader

Comment by binary132 | Hacker News Reader

Decentralized package hosting is the only way.

The key question here is how exactly the supply chain attacks will be prevented. If you consider release of new version of a library some sort of transaction, it's easy to see then the difference with cryptocurrencies: in crypto transaction can be automatically verified, but with software releases it is impossible. It is hard to imagine hundreds of hostings on the same very high trust level, so either risks become significant or there are several, but not many hostings which everyone can trust. If Number of hostings << Number of users, then it's not truly decentralized and there still exists a different risk, when there's some sort of political split between some of them. Summarizing all of that, I don't know if decentralization is a solution at all. Transparent community ownership over a centralized solution is much better.

The supply chain attack is not the only argument here, though.

For instance, who effectively controls the ruby ecosystem? See ad-hoc restrictions such as 100.000 downloads - past that point you are disowned from your own gem. I always felt that was a direct attack on independent developers. They could have forked those gems just fine (the licence permits this for most gems after all), but nope, they forbid you to remove your own (!!!) code.

Decentralization is not the answer to that though.

> The key question here is how exactly the supply chain attacks will be prevented

By using signed packages. Why is this even a question.

If it’s PKI and there’s verification on each stage, maybe. Just different sort of centralization. If keys are self-issued, it’s still a problem. Say, you add a new dependency from a repository XXX. A new version is released signed by another key, which appears to be legitimate. What are you going to do? Run full KYC on new credentials? Distrust the new dependency version and fork the library? Just ignore assuming that repo has verified it?

With central repo you may expect that they operate under increasingly stronger security standards and even if you missed malicious update, there’s higher chance that it was taken down by someone else. In decentralized environment your risks are higher and attention surface bigger.

Whence this idea that Web of Trust is an unsolved useless design that requires central certificate authorities?

The fact is that even the “canonical” CA’s can’t be automatically trusted, but here we are. CA is just one shitty implementation of WoT that has been near-universally imposed on us and most people simply accept as a necessity of life, but it isn’t necessarily the only way. It’s just how it is right now.

Web of Trust is highly theoretical concept, which is unlikely to scale well for millions of people. It's a technical solution to a people problem and we barely solved this people problem already (to a few nines, but not absolutely) - through a sophisticated centralization.

Can Gems be served from OCI Container/Artifact registries, which (also) already support signatures?

From https://news.ycombinator.com/item?id=44991636 :

> Native Containers are bare-metal host images as OCI Images which can be stored in OCI Container Registries (or Artifact registries because packages too). GitHub, GitLab, Gitea, GCP, and AWS all host OCI Container/Artifact Registries

So, packages there too would simplify.

Re: "RPM 6.0 Released with OpenPGP Improvements and Signature Checking by Default" (2025) and Sigstore and PyPI and SLSA.dev and key revocation transparency: https://news.ycombinator.com/item?id=45354568

Nerdctl supports various snapshot, lazy start, and distributed cloud storage container stores: https://news.ycombinator.com/item?id=45270468

Ruby has:

  gem cert --build your@email.com 
  gem install gemname -P HighSecurity

And also for signatures now there's sigstore-ruby and Trusted Publishing.

sigstore-ruby: https://github.com/sigstore/sigstore-ruby

guides.rubygems.org/trusted-publishing: https://guides.rubygems.org/trusted-publishing/ :

> Trusted publishing is a mechanism for uploading gems to RubyGems.org without using long-lived secret credentials. [..]

> Trusted Publishing is a term for using OpenID Connect (OIDC) to exchange short-lived identity tokens between a trusted third-party service and RubyGems.org. This allows obtaining short-lived API tokens in an automated environment (such as CI) without having to store long-lived API tokens or username/password credentials.

They could start with reproducible builds from the source git repos.

https://reproducible-builds.org/

What languages do you use that have adopted this well?

I'm not counting something like C++ where there's effectively no "packages" to speak of.

Go has decentralized package hosting and it works reasonably well.

Deno does also but I'm less clear on well how that is working out for them.

>Go has decentralized package hosting and it works reasonably well.

All go package imports are proxied via Google.

https://drewdevault.com/2022/05/25/Google-has-been-DDoSing-s...

> (you can set GOPROXY=direct to fix this)

https://drewdevault.com/2021/08/06/goproxy-breaks-go.html

Not that defaults don't matter, just offering the extra detail. And, as the post goes on to explain, this change seems to cause its own set of dependency issues.

The Deno people recently released jsr.io, "a modern package registry for JavaScript and TypeScript."

I'm not familiar with the technical details, but at first glance it appears pretty centralised.

Technically, deno supports https imports as well

https://docs.deno.com/runtime/fundamentals/modules/#https-im...

Go, for some values of "distributed". The vast majority of go packages are hosted on GitHub, but nothing stops anyone from hosting elsewhere and Go has explicit support for indirection such that anyone can use a vanity domain that happens to point at GitHub or wherever.

Go's one weakness is that the package source is baked into the package data in a not-automatically-fungible way. And if pkg.go.dev ever becomes a threat vector, we're gonna have a bad time.

dselect solved this ages ago with its mirrors, but at some point it seems every major package manager decided that was unnecessary complexity ("why bother? It's not like a package repo just goes down") and left it out when they built their alternatives.

So, from time to time, when a domain in the Internet goes sour it's a huge problem (whereas were a Debian mirror to go sour I'd add like one line to a config file and never notice the issue again, assuming dpkg doesn't automatically identify the problem and route around it).

Depending on your definition of “threat” I’d definitely consider it a threat vector already.

Isn't this the same as ruby gems, then? You can use alternative sources in your Gemfile pretty easily.

Sort of.

Go packages have the source baked into the package name. It would be like needing to say `require "github.com/sparklemotion/nokogiri"` rather than what we do today, `require "nokogiri"` and then if you want to change the source wrapping `gem "nokogiri"` in an alternate `source` block.

This is why Go’s dependency management doesn’t really qualify as “decentralized” in my mind. A decentralized provider (IPFS?) could possibly be implemented for some packages, but most of its packages are locked into centralized hosting and URLs today. Some of them sometimes being hash-identified and cache-proxied doesn’t help the case much and IMO the centralized proxying by default actually hurts it.

Depends what you're trying to decentralise. Go has no centralised registry. The collective of all the packages are decentralised, but each individual package is centralised.

go is comically un-distributed in practice:

- almost every package is hosted on GitHub and that url is baked in to consumers of those packages

- the go proxy: https://flak.tedunangst.com/post/what-the-go-proxy-has-been-...

Nowadays there are, as vcpkg and conan step by step win the earths of the C and C++ communities, and then there are the distro specific ones, if someone is happy enough with rpm/deb + pkg-config.

However I would say all ecosystems have issues, regardless of the approach, because 99% of the developers have no clue on what they depend on, and there are plenty of ways to mess up with ecosystem.

Do Linux repos not implement decentralized (perhaps “federated” is a better word here) package management?

Btw, I’m definitely not saying anything is doing this really well yet, but I do think Linux distributions are a pretty good implementation of it. I think it would be pretty difficult to stamp out Linux and Linux packages.

Is this written by a spy from a hostile country?

Yes, I hail from the Democratic People’s Republic of GNU Plus Linux

Reply on news.ycombinator.com