2 ms·

> What are actual things that crates.io or npm could do but aren’t to improve the security of the ecosystem? Go back to the distribution/maintainer model. It

> What are actual things that crates.io or npm could do but aren’t to improve the security of the ecosystem? Go back to the distribution/maintainer model. It worked. But it requires that developers slow down the rate of (non-alpha/beta/rc) releases until it matches the maintainer capacity of major software distributions. This is bitter medicine, but it's the solution. Software distributions exist for a reason. They have maintainers, who are responsible for watching for stuff like this. Unmoderated language-specific registries have encouraged a massive degree of churn. This churn is incompatible with maintainer review, which is why a lot of distributions have basically given up on language-specific registries.

vlovich123 1y ago
> Software distributions exist for a reason. They have maintainers, who are responsible for watching for stuff like this. And still completely missed the xzutils compromise. And I’m 90% sure those distribution maintainers don’t watch for stuff like this because they simply wouldn’t have the bandwidth to. I think they mostly rather just determine whether or not a software package is worth adding and maybe determining it initially and whether it has problems building. For example, the base available software in Arch is quite limited while the AUR is a choose your own adventure.
- octoberfranklin 1y ago
  > And still completely missed the xzutils compromise. There's no comparison. That was the culmination of a three-year effort -- almost certainly state-backed. Stuff like that happens maybe three times a decade, and makes headlines. Meanwhile supply chain attacks against language-specific package managers are a monthly or perhaps even weekly event. There's no comparison.
detaro 1y ago
You could do "distributions" on package registries too. Maintainers pooling up, intentionally keeping dependencies in the trusted set of maintainers as far as possible, including external ones only carefully and with pinned versions (registries that don't have namespaces are a bit annoying there), ... Or run a separate registry with reviewed packages, I'm sure we're going to see that soon as a service.
- octoberfranklin 1y ago
  The important part is the backpressure from the maintainers to the developers. Unfortunately what you propose provides no backpressure. Developers used to ask themselves "if my next version changes from requiring (libfoo>=0.3) to requiring (libfoo>=0.4), will that risk it being left out of the next Debian release?" In the C/C++ ecosystem people still ask themselves this question (or similar). Oftentimes that leads to thoughtful solutions, like being able to build against either libfoo, but simply disabling certain features if (libfoo<0.4). The churn rate and the "upgrade-all-muh-pkgs-and-hash-em-good" workflow make it painfully impractical to ask this question and give it due consideration. So we get supply chain attacks.

vlovich123 1y ago

> Software distributions exist for a reason. They have maintainers, who are responsible for watching for stuff like this. And still completely missed the xzutils compromise. And I’m 90% sure those distribution maintainers don’t watch for stuff like this because they simply wouldn’t have the bandwidth to. I think they mostly rather just determine whether or not a software package is worth adding and maybe determining it initially and whether it has problems building. For example, the base available software in Arch is quite limited while the AUR is a choose your own adventure.

octoberfranklin 1y ago
> And still completely missed the xzutils compromise. There's no comparison. That was the culmination of a three-year effort -- almost certainly state-backed. Stuff like that happens maybe three times a decade, and makes headlines. Meanwhile supply chain attacks against language-specific package managers are a monthly or perhaps even weekly event. There's no comparison.

detaro 1y ago

You could do "distributions" on package registries too. Maintainers pooling up, intentionally keeping dependencies in the trusted set of maintainers as far as possible, including external ones only carefully and with pinned versions (registries that don't have namespaces are a bit annoying there), ... Or run a separate registry with reviewed packages, I'm sure we're going to see that soon as a service.

octoberfranklin 1y ago
The important part is the backpressure from the maintainers to the developers. Unfortunately what you propose provides no backpressure. Developers used to ask themselves "if my next version changes from requiring (libfoo>=0.3) to requiring (libfoo>=0.4), will that risk it being left out of the next Debian release?" In the C/C++ ecosystem people still ask themselves this question (or similar). Oftentimes that leads to thoughtful solutions, like being able to build against either libfoo, but simply disabling certain features if (libfoo<0.4). The churn rate and the "upgrade-all-muh-pkgs-and-hash-em-good" workflow make it painfully impractical to ask this question and give it due consideration. So we get supply chain attacks.