2FA in CI

[dominykas]

The primary intent of this PR is to kick off a discussion on the various options around how 2FA could be used for publishing from CI, incl. by teams.

I listed multiple options, I'd like to hear feedback about them (I might have missed some pros/cons) and it would be nice to hear some other ideas (feel free to push commits with them, if you have to).

If we can get an agreement on which ones are worth pursuing the most - we could possibly extract them into separate issues/projects either here or under @pkgjs, but for now I just wanted to have everything in one place as a starting point.

I know there's opinions about whether it is a good idea to publish from CI, but I think that's a discussion for CI/CD and publishing guidelines - the fact is that people are publishing from CI and they are not using 2FA, and that needs to be fixed (and I don't think that asking them to not use CI for publishing is something that would bring any results).

See also: #244

---

As a personal note, after I wrote down the "poor man's version" of the Release Manager approach (i.e. setting the 2FA flag on a published release post-factum), I've kind of grown to think that it might just be one of the more awesome ways forward.

At the same time, I'm actually quite excited about all the options, and in an ideal world all of them would be available for people to use.

[vweevers]

Where is the advice that the release process should be automated? Opinions differ.

[ljharb]

I very strongly believe that publishes - the only irrevocable thing - should never be automated, for many reasons (mostly around safety and auditing and having humans as the last line of defense)

[dominykas]

I hereby give such advice ;)

Then there's also https://blog.greenkeeper.io/introduction-to-semantic-release-33f73b117c8 and similar concepts.

I disagree that humans are better at this task than machines. I do however agree that this is not a one-sided decision, it has pros and cons. That said - I'm not sure that this document is a good place to weigh them up, I think that's better left for CI/CD and publishing guidelines and I'm more than happy for those to include a balanced overview of both opinions. I will see if I can find the time to make the necessary suggestions there myself, unless there's someone who can do that sooner.

So anyways, there is the school of thought of automated releases, there are maintainers using it, there are teams that can benefit and simplify their processes - they have no simple way of doing 2FA and that is the problem we're trying to solve here.

[vweevers]

Right, this document could focus on the how of automating releases, not the why. It just needs a small tweak, because the current wording makes it sounds like automating the release process is considered a best practice by the package-maintenance team. Which - judging by @ljharb's comment - is not established, or even discussed yet.

[dominykas]

Sure, I'll see how to update the wording (happy to take suggestions).

Some prior discussions in #244.

The document title does only mention 2FA as a baseline practice. It's also a draft PR for a drafts folder ;) I wasn't sure about the best approach to open up the different options for discussion - the intent is to slim them down and open separate issues if need be. Haven't had time to write an intro for the PR :)

[dominykas]

@vweevers does 09035d7 sound better?

Also added the PR description.

[vweevers]

Perfect

[wesleytodd]

Sorry I only had time to read half right now (I started on a new team on Monday and have been very busy with the switch), but this is great!

[boneskull]

This is a good overview of the problem, thanks

[isaacs]

We just had a brief discussion on this topic in our npm team standup.

I intend to write up a brief RFC describing a staged publish support in the registry package document. I'm going to avoid some of the various angles discussed here and try to keep it focused on what we can likely accomplish within a reasonable time window.

tl;dr of what I'm thinking:

• you can "stage" a publish by adding it to the "stagedPackages" object in the packument
• stagedPackages do not reserve the version number. However, when a version is moved out of staging and into versions, the number is reserved, and any staged packages for that version are deleted.
• a new npm command to promote a staged publish to a real publish
• stagedPackages will be associated with a tarball artifact, so you can install them (for testing etc) by specifying the tarball URL.
• TBD:
  • permissions around who has rights to stage vs promote vs publish
  • possible npm option to include stagedVersions in install target list
  • Any UX (other than CLI and API) around release management, staging, etc.

I think this would give us a useful building block to start tackling some of the other stuff discussed here.

[wesleytodd]

This sounds great @isaacs! I think that what you have outlined here will really help, but the critical piece of integrating 2FA into the promote doesn't seem covered. If you could do this on the registry website with a button click which required re-auth and 2FA that would be AWESOME! So the sooner we can tackle that last TBD item the better :)

[wesleytodd]

Hm, actually I wonder....maybe I was wrong that we need more than a cli. I think having some user stories in the RFC would help here, because now that I am thinking about it you could have CI do the staged publish and then have the owner just run the promote from the cli with an OTP. I guess that does solve that use case in a minimalist sense.

[ljharb]

That's the workflow I envision; CI staging publishes, but the user explicitly promoting it (via CLI, and optionally in the future, the web UI)

[darcyclarke]

As a follow up to @isaacs's initial comment, we've just posted an RFC outlining what that initial set of work/features might look like here: npm/rfcs#92

[ruyadorno]

@dominykas here's the link to the npm public events calendar that has the reference to each OpenRFC meeting: https://calendar.google.com/calendar/embed?src=npmjs.com_oonluqt8oftrt0vmgrfbg6q6go%40group.calendar.google.com (it's a bi-weekly happening meeting every other Wednesday)

[dominykas]

Removed the agenda label until there's something more to discuss.

My plan is to wait for npm/rfcs#92 and I will then rephrase this to list the existing options as such, rather than the theoretical approaches on how this can be solved (might do that sooner, time permitting).

[bnb]

May also want to consider adding something about npm access tokens.

https://docs.npmjs.com/creating-and-viewing-access-tokens

[thescientist13]

These efforts are happening as well, maybe worth including or tracking in an issue to further refine this doc as progress is made

• https://github.blog/2022-02-01-top-100-npm-package-maintainers-require-2fa-additional-security/
• https://github.com/mmarchini-oss/npm-otp-publish

[simoneb]

We have developed this which we're using to publish our npm packages with as much automation as having 2FA enabled in NPM allows. It's not a perfect solution but it works pretty well for us.

https://github.com/nearform/optic-release-automation-action

[dominykas]

I'd appreciate if someone could re-read this and make some suggestions with updates on the state of things in 2022!

[thescientist13]

Not sure we want to add a link to this to the repo's docs TOC as well?

[thescientist13]

I think these all got promoted out of drafts recently, so we may want to double check the link and remove the draft label

[thescientist13]

Note: at the time of writing neither documents or gives advice on using two-factor authentication when publishing.

Suggest removing or

[thescientist13]

I wonder if manual approval, now available in GitHub Actions could be "hacked" to make this work? From what I see in that blog post, folks can leave a comment. Maybe that comment could be the OTP and then the build script could leverage the GitHub API or even the current process / action to grab that and supply it to npm publish?

[pi0]

Interesting idea but wouldn’t the comment be public?

(time based) OTPs can be used multiple times within valid time window. Bad actors can watch for comments and immediately reuse same OTP for another action.

[dominykas]

It seems staged publishing is no longer on the roadmap: npm/roadmap#9 (comment)

I might actually see if I should start revisiting this doc sooner than I thought...

[ljharb]

Yeah, it’s very disappointing, since it’s the only path to securely and reproducibly publishing anything.

[simoneb]

Is this PR getting anywhere? It's been amusingly open for several years now

[ljharb]

At this point, the only approach for actual 2FA in CI remains something like https://github.com/GoogleCloudPlatform/wombat-dressing-room or https://github.com/step-security/wait-for-secrets (the latter of which i use on eslint-plugin-react, the only package i publish from CI from so far).

With the "web" login, I suppose you could potentially remove the need for an external server, but I haven't investigated that yet.

[dominykas]

I'm not sure I have enough capacity right now to rewrite any of the documentation here - these are mostly just design proposals.

In terms of implementation - given the age of this - I'm not sure any of the implementations are moving ahead or gaining significant traction to be called a common pattern... Maybe there's people somewhere else working on/discussing something similar?

Optic is as close as it gets (although it's grown up with a bunch more opinions), but the UX of all of these tools is just not there.

From my perspective, hitting the "Close" button on this PR is easy enough 🤷‍♂️ Maybe I should just do that?

[wesleytodd]

From my perspective, hitting the "Close" button on this PR is easy enough 🤷‍♂️ Maybe I should just do that?

I am not sure there is any benefit to doing that. At least with it being open that is a signal to new folks who might like to pick it up and get it updated. Maybe editing the original post with an update that it is "looking for help" and then you could just fun-ollow the thread?