When will we learn?

Tools
1

https://drewdevault.com/2022/05/12/Supply-chain-when-will-we-learn.html

This article makes a good case for why Linux Distro packages add significant security value over language package managers like Npm, Cargo, etc. These are tradeoffs – language package managers provide value in that they allow people to move much faster. It is interesting that I can’t find any malicious Go packages. Perhaps publishing the entire source URL as the package name helps as this is harder to take over? However, a Github account could still be compromised – especially for an abandoned package. At any rate, I like the way Go does packages as there is a more direct link between the package name and the source code. Sylvain Kerkour thinks so too:

Packages management

I don’t like centralized package repositories. They add complexity and obfuscation, all while supply chain attacks are increasing.

It is possible to import packages from Git in Rust, but as it’s not the “official” way, the packages you import from Git will surely import packages from crates.io themselves :man_shrugging:

So please, follow the Go model: centralized discovery but decentralized distribution. It’s not perfect, but it certainly reduces the chances of a successful supply chain attack.

Another article:

https://kerkour.com/supply-chain-attacks-and-backdoored-dependencies

Are supply chain attacks and backdoor unstoppable?

I don’t think so, but I think that the current model of centralized package managers needs to end. Centralized package repositories add layers of obfuscation and complexity, which is only good for attackers.

I think that a better model for package management is decentralized distribution with centralizedd search.

This is why I think that today, Go has the best approach to supply chain security: Git-based dependency distribution, which enables easier auditing, a centralized database of modules’ content so that everybody get the same code for a given module@version, and no build-time scripts.

While we will never be able to stop the compromise of 3rd party libraries, we can do our best to ease the detection.

2

There’s nothing stopping a rolling release Linux distro from packaging things basically just as fast as the centralized language-specific package repos. There’s no solid reason other than developer time/effort/sanity which prevents something like Debian Sid from always being within a day or two of the latest release of every npm package, let along something like Arch.

The hard part is balancing being able to offer both the bleeding edge as well as older, more stable, more tested, and likely more used versions of the same packages. And to make sure they all work nicely together. For things like npm, this due diligence falls on the poor developer who’s gluing them all together. For traditional Linux distributions, the package maintainers often take this role on, which is why they move slower.

If you’re a hobby developer or working on a very small but talented team, you probably love living on the bleeding edge. If real money depends on your code working, maybe you shouldn’t live on the bleeding edge. Each comes with its own tradeoffs. I think having both modes of operation is a good thing even if I’m firmly in the “Linux distros are the right way to do this” camp.

2 Likes