2FA needs to be required for publishing packages. An attacker compromising someone's CI should not give them free reign to publish malicious packages at any time they want.
2FA needs to be required for publishing packages. An attacker compromising someone's CI should not give them free reign to publish malicious packages at any time they want.
In a lot of cases, it's not really clear whose second factor would authorize publishing a package that was uploaded from a CI/CD system. Is it any project owner? Anyone from the same GitHub organization? etc.
> An attacker compromising someone's CI should not give them free reign to publish malicious packages at any time they want.
Agreed, that's why a lot of packaging ecosystems (including PyPI) have moved towards schemes that involve self-scoping, self-expiring tokens. The CI can still publish, but the attacker can no longer exfiltrate the publishing credential and use it indefinitely later.
(These schemes are not mandatory, because they can't be.)
The 2FA of whatever account is publishing the package. I'm pretty sure Pypi already has this figured out except they seem to allow you to make an API key which just bypasses checking a 2nd factor.
Which account is publishing the package, in a CI/CD context? It's not clear that any particular account is, since the set of people who can trigger a workflow in CI/CD aren't necessarily (and in fact aren't often) the same set of people who can create an API token on PyPI.
The user that owns the API key or whoever it already associates what account is doing the publishing. It isn't a new problem.
but then how can we deploy our vibe coded PRs we didn't review at a pace of 40 deploys per day?
Sounds like 2FA should be required for CI.