Add release workflow

[blakeembrey]

Adds a release workflow in GitHub Actions.

[jonchurch]

Idk that I have anything new to add, so I suppose I'll list the tradeoffs as I've clarified my understanding over the past few months.

The threat model that I want to see us operate under is that a compromise of a repo admin's Github PAT cannot lead to an npm publish. E.g. npm i in the 2 hour window when there's malware in someone's dep tree somewhere and I get my github cli PAT exfiled.

Today we are protected via local publishing w/ 2fa npm gate.

The tradeoff w/ TP is that we gain release automation, but we become vulnerable to the above threat. We do not currently use any npm tokens in CI, so the TP benefit of obseleting them does not apply to us.

I went down the rabbit hole on all the Github 2fa gates for Trusted Publishing I could think of, envionments w/ required approvals, verifying tags are signed by a known key, etc.

The core issue with gating at Github is a "fox in the the hen house" problem where:

• Any gate we can configure lives in Github settings, or workflows
• A compromised repo admin PAT is sufficient to disable all those gates, via API calls to reconfigure environments (dropping required reviewers, allowing self approval, tampering w/ workflows, rewriting branch protection).
• No 2fa is required to do the above via the API (I verified the environment tampering via gh cli with a dummy repo)

(claude has more technical terms for the structural issue: "GitHub's auth domain and config domain are the same trust domain. A token that can act on the repo can also rewrite the rules governing how the repo can be acted upon.")

I know none of that is in this PR, but I have been trying to figure out how to harden a TP model bc the workflow in the PR (which is the recommended setup by githhub/npm) is susceptible today to someone w/ tag push access having their GH PAT compromised.

I don't think TP can satisfy the threat model I desire of "a compromise of a repo admin's Github PAT cannot lead to an npm publish."

I evaluated the step security wait-for-secrets approach of eschewing TP and bringing in an external workflow to bring back 2fa prompt. It relies on long (90 day) lived tokens in CI, but it at least closes the risk of a gh token exfil leading to publish package. Assuming that packages and user accounts are all 2fa publishing protected, an attacker can do maximal damage within a repo w/ a repo admin's stolen token but cannot cause a publish.

I dont like any of our options to be honest. My wishlist is just that there was first party CI publishing w/ a npm 2fa challenge. The Step Security workflow is closest to that, but is not TP, and has overhead that is gross (keeping people's npm tokens in repo secrets, rotating, 3rd party touching 2fa tokens). I dont like it, but it does at least pass the threat model. So idk that I'd recommend it over local publish, but if CI publish is a requirement, that does seeem like the safest one.

I wrote this all up to get my thoughts out there and see how we feel. Am I wrong about any facts here? Is there agreement on the threat model I outlined about preventing publish on repo admin compromise? Do we want to operate under a different threat model? Are we already operating under a different threat model?