2FA for publishing releases?

[mpdude]

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 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 updated to ) for a broad audience.

What do you think?

[stof]

There is nothing happening on Packagist to publish releases. Packagist does not work the same than the npm registry. Publishing a release is a matter of creating the tag on github. There is no other action to do.

[mpdude]

Yes, on NPM you upload the package itself, so it need not even be the same code that is published in the repo.

The question was more if it would make sense as an additional layer of security: Even if somebody can push malicious code/tags to your GH repository without you (immediately) noticing it, it might help if that is not distributed as a release right away, but requires some kind of additional confirmation/consent – like a 2FA code, clicking a link in a confirmation mail, ...?

If this is a dumb question, close the issue please.

[stof]

@mpdude if the tag is pushed on github, there is no maintainer action to make it available to composer today. The VCS repo is the source of truth (btw, as packagist exposes dev versions, a confirmation would have to happen for each pushed commit, not for each release).

[mariusbuescher]

Maybe an idea could be working with signed tags as a safety net.

A maintainer adds trusted gpg keys to a package and packagist checks - if this is activated and keys are available - the signature of the tag. It can then either be strict and not mark publish this release or mark it as untrusted somehow.

The concept of untrusted releases could also be something that is reflected in composer, so composer warns of those releases.

What do you think about this idea?