Hacker News new | ask | show | jobs
by cyphar 17 days ago
I'll be honest, I have always found the "trusted" publishing concept quite suspect -- the boiled-down argument is that developers are too incompetent to manage their own keys. Yes, there are obviously problems with storing plaintext publishing keys and tokens in $HOME, but that isn't the only solution. You can use hardware keys for signing (I would wager a lot of open source maintainers have at least one Yubikey or NitroKey kicking around -- they used to give them away at conferences) and for upload tokens you can even just password-protect them or require them to log in each time.

The alternative proposal with "trusted" publishing is to grant all of GitHub's automated infrastructure the ultimate authority to publish things on your behalf automatically in a way that it is shown as being more "trusted" than the developer uploading it themselves! I'm honestly surprised that it took this long for supply-chain attackers to start targeting this obvious security hole -- I doubt any user of GitHub would argue that GitHub Actions are a parogon of security, and yet the strongly recommended deployment workflow for several language communities involved bolting it into the core of your release mechanisms! I think the OCID stuff is interesting and provides some nice properties but it doesn't prove that the GHA workload is actually trusted in the sense that "trusted publishing" means.

The arguments for adding speed bumps to auto-applying updates apply just as much to adding speed bumps to doing releases (arguably even more so -- even rapidly evolving libraries don't have hundreds of releases a week). Automating everything to the nth degree just expands the blast radius when stuff like this happens.

I do all runc releases manually and sign them with a PGP key stored in a hardware token that requires a pin for every signature attempt. Yes, it's a bit more cumbersome but it certainly would be harder to supply-chain hundreds of projects of every maintainer would need to manually publish them. For some other projects that need to publish to crates.io or PyPI I was honestly a little dismayed at how prominently they push for "trusted" publishing and how little support there is for making the "dumb" publishing flow more secure (they even visually display such releases as less trusted, and the only way to get more green checkmarks is to let GitHub take the wheel).