npm has had support for package-scoped publish tokens (with optional 2FA enforcement) for a few years by now. So in case of compromise, the blast radius would be a single package.

The OP gave the GH repo too broad permissions. There is no good reason for the repo CI workflow to have full access to everything under their account.

▲

hinkley 3 days ago | parent [-]

I’m using the 2FA tokens, my complaint is that “npm publish” from my own machine has no guarantees of being an exact snapshot of trunk. And a worm could inject code into my system to do the Kernighan exploit.

I think over the last few weeks I have at least talked myself into going back to maintaining multiple user accounts on my laptop to separate personal, open source, and entertainment into separate accounts to reduce the last radius, but the fact is sometimes I like to do two things at once and that will be a pain.

▲

baobun 3 days ago | parent [-]

You can get pretty close to guarantees.

Fresh git checkout on prod publish. Run all npm/node commands in ephemeral rootless containers. Only have publish token exposed and injected when you are actually publishing (not on install/build just prior). Separating users like you mentioned doesn't hurt bt doesn't sound like your lower-hanging fruit nor something that would likely save your bacon on its own without other workflow adjustments.

None of this is relatively difficult per se, just a bit extra friction which should be worth it to avoid these kinds of events.

	▲	hinkley 2 days ago \| parent [-]
		Npm supports one time passwords, and iPhone has builtin support for the protocols that npm uses. Someone’s going to have to pickpocket me to hijack that repo. Hacking my machine with supply chain attacks would be much much easier.