3 ms·

Decentralized package hosting is the only way.

__float 1y ago
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.
- voxic11 1y ago
  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.
  - delfinom 1y ago
    >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-sourcehut.html https://drewdevault.com/2022/05/25/Google-has-been-DDoSing-s...
    - lcnPylGDnU4H9OF 1y ago
      > (you can set GOPROXY=direct to fix this) https://drewdevault.com/2021/08/06/goproxy-breaks-go.html 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.
  - monooso 1y ago
    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.
    - leleat 1y ago
      Technically, deno supports https imports as well https://docs.deno.com/runtime/fundamentals/modules/#https-imports https://docs.deno.com/runtime/fundamentals/modules/#https-im...
- zrail 1y ago
  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.
  - shadowgovt 1y ago
    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).
    - binary132 1y ago
      Depending on your definition of “threat” I’d definitely consider it a threat vector already.
  - cortesoft 1y ago
    Isn't this the same as ruby gems, then? You can use alternative sources in your Gemfile pretty easily.
    - zrail 1y ago
      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.
      - 1y ago
- pjmlp 1y ago
  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.
- binary132 1y ago
  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.
ivan_gammel 1y ago
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.
ergocoder 1y ago
Is this written by a spy from a hostile country?
- binary132 1y ago
  Yes, I hail from the Democratic People’s Republic of GNU Plus Linux

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.

voxic11 1y ago
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.
- delfinom 1y ago
  >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-sourcehut.html https://drewdevault.com/2022/05/25/Google-has-been-DDoSing-s...
  - lcnPylGDnU4H9OF 1y ago
    > (you can set GOPROXY=direct to fix this) https://drewdevault.com/2021/08/06/goproxy-breaks-go.html 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.
- monooso 1y ago
  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.
  - leleat 1y ago
    Technically, deno supports https imports as well https://docs.deno.com/runtime/fundamentals/modules/#https-imports https://docs.deno.com/runtime/fundamentals/modules/#https-im...
zrail 1y ago
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.
- shadowgovt 1y ago
  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).
  - binary132 1y ago
    Depending on your definition of “threat” I’d definitely consider it a threat vector already.
- cortesoft 1y ago
  Isn't this the same as ruby gems, then? You can use alternative sources in your Gemfile pretty easily.
  - zrail 1y ago
    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.
    - 1y ago
pjmlp 1y ago
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.
binary132 1y ago
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.

ivan_gammel 1y ago

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.

ergocoder 1y ago

Is this written by a spy from a hostile country?

binary132 1y ago
Yes, I hail from the Democratic People’s Republic of GNU Plus Linux