2FA for publishing releases?

A few days ago, the `ua-parser-js` NPM package was compromised. A postinstall script was used to install a crypto miner and exfiltrate passwords from machines where the package was installed. The package is a dependency for a broad range of other (possibly even more popular) packages. See https://github.com/advisories/GHSA-pjwm-rvh2-c87w for details.

It seems the malicious versions were be published after the package maintainer's NPM account credentials were stolen and they did not have 2FA enabled.

I am trying to learn from this what I can do on my end to prevent things like this from happening. In this context, I also noticed that NPM has a dedicated setting to require 2FA when publishing package versions.

Is that something special to the way NPM works (which I do not know much about), or would it be a useful enhancement for Packagist as well?

My guess is that most packages on Packagist will automatically be updated/published once a new version tag is pushed to GitHub.

So, on the one hand, you could (rightfully) say that once a malicious actor is able to push commits or tags under your name into your repository, you've lost the game already. So, take care to protect your GitHub credentials, use only SSH keys for Git authentication/transport. Enable 2FA for github.com logins.

On the other hand, 2FA-based approval for updating published packages could add an additional security layer: Even if you manage to push malicious code to some repository, you could not at the same time make it available (and possibly be `composer update`d to ) for a broad audience.

What do you think?

No files, tests, or entry points are identified. Start by mapping Packagist's package publishing flow and its existing authentication controls, then determine whether a 2FA approval step is feasible; done would be a documented, agreed design or an implemented publishing safeguard with tests.

Written by the indexing model from the issue text.