github, pypi, npm, homebrew, cpan, etc etc. should adopt a multi-multi-factor authentication approach for releases. Maybe have it kick in as a requirement after X amount of monthly downloads.
Basically, have all releases require multi-factor auth from more than one person before they go live.
A single person being compromised either technically, or by being hit on the head with a wrench, should not be able to release something malicious that effects so many people.
They would have to find someone else if they grew too big.
Though, the secondary doesn't necessarily have to be a maintainer or even a contributor on the project. It just needs to be someone else to do a sanity check, to make sure it is an actual release.
Heck, I would even say that as the project grows in popularity, the amount of people required to approve a release should go up.
So if I'm developing something I want to use and the community finds it useful but I take no contributions and no feature requests I should have to find another person to deal with?
How do I even know who to trust, and what prevents two people from conspiring together with a long con? Sounds great on the surface but I'm not sure you've thought it through.
It wouldn't prevent a project that has a goal of being purposely malicious, just from pushing out releases that aren't actually releases.
As far as who to trust, I could imagine the maintainers of different high-level projects helping each other out in this way.
Though, if you really must allow a single user to publish releases to the masses using existing shared social infrastructure. Then you could mitigate this type of attack by adding in a time delay, with the ability for users to flag. So instead of immediately going live, add in a release date, maybe even force them to mention the release date on an external system as well. The downside with that approach is that it would limit the ability to push out fixes as well.
But I think I am OK with saying if you're a solo developer, you need to bring someone else on board or host your builds yourself.
Or just don't install every package on the earth. The only supply-chain attack I've been affected by is xz, and I don't think anyone was safe from that one. Your solution wouldn't have caught it.
Better to enforce good security standards than cripple the ecosystem.
Why not make it _optional_ but implement on github,etc so any publisher could enable this, no matter how small. But also make it possibel to disable either by support request and small wait or by secondary confirmation or via LONG (months) wait.
I really hoped PyPI's required switch to 2-factor auth would require reauthorization to publish packages. But no, they went with "trusted publishing" (i.e., publishing is triggered by CI, and will happily publish a compromized repo). Trusted publishing would only have been a minor hindrance to the litellm exploit. Since they acquired an account's personal access token, the exploit could have been committed to the repo and the package published.
Basically, have all releases require multi-factor auth from more than one person before they go live.
A single person being compromised either technically, or by being hit on the head with a wrench, should not be able to release something malicious that effects so many people.