More restrictions on API keys

[ioquatix]

Expanding on #2601

I think ideally what I'd like is:

• API key specific to one or more gems (minimise blast radius if compromised).
• Enable/disable OTP requirement per key (allow for automated use).
• Ability to specify key via command line e.g. ENV (don't need to write it into ~/.gem/credentials).

The value in this is to allow per-project API keys which can publish gems.

Edit: third point is already supported. use --otp or GEM_HOST_OTP_CODE env rubygems/rubygems#4697

[duckinator]

Came here to say basically exactly this. I went to automate a release of a gem like I do with my Python packages, and it turns out I can't do so without reducing the security on my entire account, or setting up a second account.

[jchestershopify]

Should this be a single issue or broken down into standalones? I ask because I can think of at least two other wishlist items: that push tokens can only push (because token leaks are likely to occur in CI/CD), and that all tokens expire without exception (following the Let's Encrypt precedent).

[ioquatix]

As long as token expiration is something decent like 12 months I'd be fine with it.

[jchestershopify]

I'd argue for more frequently -- 12 months is long enough that people totally forget about how they rotated the token last time. Let's Encrypt set their expiries at 90 days to encourage routines and automation.

[duckinator]

To me, an expiration time of 90 days or 6 months seem like the best options. 12 months might be okay.

It feels like a "sweet spot" where the maintenance burden for not automating it is only a periodic concern, but the tokens still gets cycled regularly.

[simi]

API scoped gems were added at #2944, closing for now 💪