4 ms·

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, i

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.

shevy-java 1y ago
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.
- ivan_gammel 1y ago
  Decentralization is not the answer to that though.
lelanthran 1y ago
> The key question here is how exactly the supply chain attacks will be prevented By using signed packages. Why is this even a question.
- ivan_gammel 1y ago
  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.
  - binary132 1y ago
    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.
    - ivan_gammel 1y ago
      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.
- westurner 1y ago
  Can Gems be served from OCI Container/Artifact registries, which (also) already support signatures? From https://news.ycombinator.com/item?id=44991636 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 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 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 https://github.com/sigstore/sigstore-ruby guides.rubygems.org/trusted-publishing: https://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.
pabs3 1y ago
They could start with reproducible builds from the source git repos. https://reproducible-builds.org/ https://reproducible-builds.org/

shevy-java 1y ago

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.

ivan_gammel 1y ago
Decentralization is not the answer to that though.

lelanthran 1y ago

> The key question here is how exactly the supply chain attacks will be prevented By using signed packages. Why is this even a question.

ivan_gammel 1y ago
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.
- binary132 1y ago
  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.
  - ivan_gammel 1y ago
    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.
westurner 1y ago
Can Gems be served from OCI Container/Artifact registries, which (also) already support signatures? From https://news.ycombinator.com/item?id=44991636 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 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 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 https://github.com/sigstore/sigstore-ruby guides.rubygems.org/trusted-publishing: https://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.

pabs3 1y ago

They could start with reproducible builds from the source git repos. https://reproducible-builds.org/ https://reproducible-builds.org/