The npm community forum has been discontinued.
To discuss usage of npm, visit the GitHub Support Community.
Allow subset of tokens to bypass 2FA requirement
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.
related to Publish on CI with 2fa?
I’m not sure this is possible at all right now, but I’m checking on it
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.
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
- 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.
There’s work being done on temporary tokens: Time-limited tokens
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?
this topic has come up directly with
semantic-release. would love to get thoughts from the npm team on that thread, if possible.
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.
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.
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!
sounds good. thanks!
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.
I can help you with your issues ,? .