Allow subset of tokens to bypass 2FA requirement

registry
security

(Ian Remmel) #1

I’d like to enable full 2FA on my account, but that prevents me from using Semantic Release in my CI tool of choice. It would nice if, using the Tokens UI, I could create a token that bypasses 2FA.


(Kat Marchán) #2

related to Publish on CI with 2fa?

I’m not sure this is possible at all right now, but I’m checking on it :slight_smile:


(Matt Travi) #3

big +1 here. i use semantic-release to publish all of my packages, which prevents me from enabling 2FA more strictly than auth-only. since semantic-release doesn’t yet support pre-releases, i do sometimes publish those locally, but would be able to enter a 2FA token in those cases.

since i only publish from travis, i limit the token used by semantic-release to the IPs of the travis instances.

bonus points: the publish notification emails immediately became noise to me since most publishes are completely automated. if i could disable the emails for publishes by the token used by semantic-release, as long as they are from the IPs limited by the token, i think i would actually find the emails useful because they would highlight publishes that don’t follow the normal process.

i’d love to get (and actually notice, once the noise is reduced) emails when:

  • a publish occurs from a token that hasnt been excluded (i would only exclude the one used on CI by semantic-release)
  • a token that has been limited to specific CIDR ranges is used somewhere that doesn’t match (probably stolen by someone that doesnt realize the limitation, but i’d like to know that they got ahold of it)

i’m happy to split these ideas out separately, but i think they are related enough that i wanted to bring them up initially in the same context.


(Kat Marchán) #4

There’s work being done on temporary tokens: Time-limited tokens


(Matt Travi) #5

There’s work being done on temporary tokens

i’ve been following that conversation, but i don’t think it ends up solving this use case very well.

The whole point of using semantic-release is to fully automate the publish process once new features react master (the chance to ensure they are safe to release relies on how you promote changes to master). the use of temporary tokens would require making a new token available to the CI server for every release.

even replacing my old tokens after all tokens were revoked has been quite the chore. i certainly wouldn’t want to need to do that for every release.

am i overlooking something with the temporary tokens thread that would enable use of temporary tokens that wouldnt involve user interaction somehow?


(Matt Travi) #6

this topic has come up directly with semantic-release. would love to get thoughts from the npm team on that thread, if possible.


(Kat Marchán) #7

If you want a more detailed discussion with actual feedback from npm folks, and not a casual conversation about it, you should probably write an RFC that describes the behavior you think you’d like from this. We do weekly RFC reviews and discussions and it’s much easier to bring ideas to the rest of the team when they’re better formulated and self-contained than a forum thread with miscellaneous ideas.


(Matt Travi) #8

fair enough. wasn’t sure if yet another security proposal would be seen as too noisy going directly to an RFC since I’m sure you’ve been hearing plenty of random suggestions lately.

my team’s use case is on the extreme end of automation, so i’m happy to provide information that can hopefully be helpful in rounding out the spectrum of publishing flows. i’ll try to find time soon to get my thoughts together a little more formally.


(Kat Marchán) #9

I think this space still seems open enough to suggestions that an RFC would be most welcome, specially from folks using semantic-release and such tools more aggressively!


(Matt Travi) #10

sounds good. thanks!


(Matt Travi) #11

still needs some work, but i opened a PR for an initial iteration of an RFC for this. more detail to come, but feel free to provide early thoughts there.