While multiple authors' signatures would be nice, a lot of these kinds of attacks would be solved if there was any signature verification being done of the commits, tags, or generated artefacts at all.

People like to complain about distribution packaging being obtuse, but most distributions have rich support for verifying that package sources were signed by a key in a keyring that is maintained by the distribution. My (somewhat biased) view is that language package managers still do not provide the same set of features for validation that (for instance) rpmbuild does.

The release process for runc has the following safeguards:

    * As the upstream maintainer of runc, our releases are all signed with one of a set of keys that are maintained in our repo[1]. Our tags are also signed by one of the same keys. In my case, my key is stored in a Yubikey and so cannot easily be exfiltrated.
    * Our release scripts include a step which validate that all of the keys in that keyring file are valid (sub)keys registered to the GitHub account of a maintainer[2]. They also prompt the person doing the signing to check that the list looks reasonable before signing anything[3].
    * Distributions such as openSUSE have a copy of the keyring file[4] and the build system will automatically reject the build if the source code archive is not signed. Our official binary releases are also signed and so can be validated in a similar manner.

Maybe there are still gaps in this setup, and I would love to hear them. But I think this setup would have blocked this kind of attack at several stages. I personally don't like the idea of signing releases in CI -- if you really want to build your binaries in CI, that's fine, but you should always require a maintainer to personally sign the binaries at the end of the process.

For language package managers that do not support such a workflow, trusted publishing is a less awful setup than having long-lived publishing keys that may be incorrectly scoped (as happened in this case) but it still allows someone who gains access to your GitHub account (such as by stealing your cookies) to publish updated versions of your package with very little resource. GitHub supports setting a mandatory timeout for trusted publishing but the attacker could easily disable that. If someone got access to my GitHub account, it would be a very bad day but distributions would not accept the new releases because their copy of our keyring would not include the attackers keys (even if they added them to my account).

Disclaimer: I work at SUSE, though I will say that I would like for OBS to have nice support for validating checksums of artefacts like Arch and Gentoo do (you can /theoretically/ do it with OBS services or emulate it with forcelocal -- and most packages actually store the archive in OBS rather than pulling it at build time -- but it would be nice to do both).

[1]: https://github.com/opencontainers/runc/blob/v1.4.0-rc.1/runc... [2]: https://github.com/opencontainers/runc/blob/v1.4.0-rc.1/scri... [3]: https://github.com/opencontainers/runc/blob/v1.4.0-rc.1/scri... [4]: https://build.opensuse.org/projects/openSUSE:Factory/package...

▲ rectang 5 days ago | parent [-]

Very well said — I agree with all points. But is NPM culturally averse to such mechanisms, and will they reject them as an imposition on authors even as the pace of successful supply chain attacks accelerates?

I think that one hole is that even if you require signatures, not all authors will adhere to best practices and some will still be compromised.

Also, five-dollar-wrench attacks remain feasible, although I’m uncertain if we’ve seen them in the real world.

	▲	cyphar 5 days ago \| parent [-]
		I think the five-dollar-wrench attack has a similar risk profile to a maintainer introducing a security flaw (intentionally or not) -- unless you are actively auditing the code of your dependencies you are ultimately trusting the upstream maintainer (as well as their personal security) at some level. Except in the most extreme scenarios I think that this kind of trust is irreducible -- if you don't trust the upstream maintainer you shouldn't use their software. The main issue I have is that these ecosystems add so many other layers of trust you need to have that are unnecessary (trust that source forges like GitHub won't ever be compromised, trust that the access control of said source forges won't ever be compromised, trust that the per-language package repos won't ever be compromised, trust that API keys won't be leaked without being discovered quickly, etc etc).