CI Publish with Two-Factor Auth for Teams

[wesleytodd]

All package publishes should be done with 2FA enabled. This requirements means that publishing from CI is difficult because it requires the CI to have a OTP from the user. In order to maintain the 2FA you need some third party setup (a api to orchestrate the 2FA). @dominykas and the team at Near Form have done some exploratory work on this with Optic. This situation is even more complicated for teams managing publish access (like we want for Express).

The POC solves well the CI portion for a single maintainer, but it requires a infrastructure which I am not sure is best long term for OSS projects. It uses web push, so requires a Firebase account. Any infrastructure requirement is complicated for typical OSS maintainers. This is also vendor lock in.

In looking for options for a setup in Express, @dominykas and I hoped on a call to discuss. The outcome from that call was that we identified one clear best case scenario:

Npm builds a release manager which supports 2FA. So the idea would be that when CI pushed a release, it would be held in a pending state if it requires 2FA but no OTP was provided. You could then visit the website to see a list of pending releases. There you provide your 2FA OTP upon "approving" the release.

I am sure there are design and technical considerations to this approach, but we thought we should bring it up here and see what people think about this proposed solution. There are other approaches we discussed, and if I have time I will follow up with descriptions of those, but I wanted to get this posted to open up the conversation asap.

[ljharb]

I’m skeptical overall of having “not a human” do the one irrevocable thing, publish. imo the best practice is to have a human do the publishing, as the final defense against misclassified semver or other publishing bugs.

[wesleytodd]

I fully understand the concern. I personally am not just talking about automated releases necessarily. This problem even exists if the situation where a human clicks a button to run a CI job. On express we have talked about this as a possible way to have more publishers without compromising security.

final defense against misclassified semver or other publishing bugs.

Very valid concern, that said not everyone is as careful as you or thinks that is a humans job (semantic release for example). I think there is value in having a good story around managing automated or CI releases as a way to lessen the load on busy maintainers. It won't be right for everyone, but for those who need it it can be super helpful.

All this said, the original concern was how teams can manage publishing access when all it takes is one compromised publisher to take down the who ecosystem. If there are other approaches to this, I would love to hear ideas of how we can manage this risk.

[ljharb]

Compromising the CI publish token results in the same risk, so i think that the approach is unrelated do the original concern.

Perhaps npm could build a system where packages with multiple owners had to have multiple owners sign off on a pending publish, pursuant to rules configurable per package (and visible to users) - but i can’t think of anything “not npm” can really do at this point to mitigate the risk.

[wesleytodd]

Compromising the CI publish token results in the same risk, so i think that the approach is unrelated do the original concern.

Yes but if you build it properly you can prevent things like npm i from running on a box with a npm publish token. Doing this for all maintainers is more difficult than for one CI job.

but i can’t think of anything “not npm” can really do at this point to mitigate the risk.

We had a few ideas on this around using an intermediary service which held publish keys and was hooked into the publish flow. See the project Optic linked above. But I agree that npm is the best place to solve this problem.

[Eomm]

I think 2FA it is a matter of security where you have doubled the things a thief must steal.
So if you maintain these two things separated you could think to avoid the "dead man's switch".
Anyway, I like to have control of the publish, but maybe I push the publish button not so often.

[fun note] I built up some workarounds for this purpose with a bunch of server in different countries a many firewall (I was constrained 🤣):

const twoFactor = require('node-2fa')
var newOtp = twoFactor.generateToken('MY BOSS TOTP TOKEN')
console.log( { newOtp } ); // use the OTP in your CI publish

[mhdawson]

@darcyclarke @ahmadnassri, has there been any discussion within npm on this topic that you could share?

[wesleytodd]

I heard on the twitters that some sort of staged release was on the roadmap at one point 🤞

[dominykas]

@dominykas to write up things we can do with and without npm's involvement.

[darcyclarke]

@mhdawson @wesleytodd Apologize for the delayed response here.

I'll see if I can't address a few of the points made in the initial issue:

1. publishing from CI is difficult

• Understandable & unfortunate; I wish we had a better story around this today.

2. [paraphrased scenario] npm builds a release manager which supports 2FA

• I poked around internally and, unfortunately, it doesn't sound like this is something we have on our immediate radar. You're more likely to find that we'll ship org-wide 2FA enforcement before setting our eyes on a release manager with push to release.

3. All package publishes should be done with 2FA enabled.

• Totally agree and you probably already know that npm supports enforcing 2FA for publishing individual packages (image attached). That said, only 0.6% of all packages and 6.89% of all maintainers have 2FA turned on respectively (definitely metrics we'd love to try and improve).

Note: for any net-new capabilities we ideally try to surface meaningful data backing up the need/impact. We definitely want to support maintainers as best we can but if we were able to find data points around potential usage it would help with prioritizing this work.

---

Other Options...

In terms of supporting your efforts as they stand today, I think it might be best to avoid creating/maintaining a proxy OTP generator or publishing service; Instead, create a CI-specific user account and add them as a collaborator/author to your team/project. Then, generate an npm auth token that you pin to/use with your CI/CD environment (ex. GitHub Actions).

Definitely let me know if you think I've missed the mark or sentiment of this thread at all but hopefully some of the above is helpful insight/guidance.

[lholmquist]

Instead, create a CI-specific user account and add them as a collaborator/author to your team/project. Then, generate an npm auth token that you pin to/use with your CI/CD environment (ex. GitHub Actions).

I think this is a solid approach. It is similar to the concpet of a ServiceAccount in the Openshift/Kubernetes world

[bnb]

Totally agree and you probably already know that npm supports enforcing 2FA for publishing individual packages (image attached). That said, only 0.6% of all packages and 6.89% of all maintainers have 2FA turned on respectively (definitely metrics we'd love to try and improve).

@darcyclarke For what it's worth, most maintainers I've talked to have very consistently asserted that the reason they don't enable 2FA on publish is because the lack of a mechanism to actually publish following the current best practices that enables them to manually publish outside of having to run npm publish locally.

Unfortunately, until there's actually a mechanism to securely publish from a build, I don't think these numbers are going to change substantially.