Rubygems.org: Automatically respond to API token leaks on GitHub (via GitHub secret scanning)

[greysteil]

Is your feature request related to a problem?

Token leaks happen. The RubyGems.org token is already pretty best practice for making it easy to detect but I couldn't find any discussion about automatically responding when leaks happen.

I'd like RubyGems.org to automatically revoke any credentials that are leaked into a GitHub public repo. I run the GitHub secret scanning team, so I can provide you with a feed of potential matches we find in public repos, if you're willing to take action on them automatically.

Describe the solution you'd like

RubyGems.org would have an endpoint for receiving details of leaked secrets from GitHub, following the specification here. RubyGems.org would automatically revoke leaked secrets, and would email their owners to notify them that they had been revoked. The email would include details of where the secret had been exposed (as provided by GitHub).

Describe alternatives you've considered

• RubyGems.org could notify users of leaked secrets, but not automatically revoke them. However, this would leave leaked credentials exposed.
• RubyGems.org could make it possible for tokens to revoke themselves, and GitHub could call that endpoint with tokens it finds. This would be a little weird though - when GitHub finds a token we don't obviously have "permission" from the user to auto-revoke it. It's not our token, either as issuer or user, after all. The comms to the user would also be a bit generic if they didn't say "this was revoked because it had been leaked".

Additional context

GitHub has a similar setup with AWS and a bunch of other partners - if you leak your AWS credentials on GitHub you'll quickly get an email from AWS saying the credential has been quarantined. Under the hood, they're receiving the feed of matches from GitHub.

I'm happy to contribute a PR for this, but would need some help from the RubyGems team.

[sonalkr132]

RubyGems.org would automatically revoke leaked secrets, and would email their owners to notify them that they had been revoke

Yes please :pray: We deployed changes to our API key format (https://github.com/rubygems/rubygems.org/pull/1962) with Github secret scanning in mind. If you can set up this automation for "rubygems_#{SecureRandom.hex(24)}" it would great. You can reach out in #ruybgems-org slack for any help you may need.

As for legacy keys format SecureRandom.hex(16), I am no so sure. Perhaps you have a better idea about how many false positives it may have.

[arthurnn]

👋 , @greysteil let sync on this, I think I can help out on the dev of the API if needed.

[greysteil]

Awesome! @arthurnn I had forgotten you were a maintainer here - I'll ping you on Slack!

@sonalkr132 - between Arthur and I we should be able to make this happen, at least for the new token format. 😄

[rubyFeedback]

Hmm. I have nothing against the proposal as such; and I agree with making things more
secure, letting people know about problems, transparency etc....

There is just one consideration or perhaps question:

• Will this impact rubygems authors? E. g. if there are changes that may then affect them
  and have them change something. For example, this part in particular:

"RubyGems.org would automatically revoke leaked secrets, and would email their owners to notify them that they had been revoked."

Would this imply that these developers are forced to change passwords?

I hope I am not too negative or pessimistic; I am a natural sceptic in general. :)

But my question is more aimed at the "are there any potentially downsides to
this change in regards to rubygem authors". Because that may then mean they
have to invest more time ... and that's not always epic if that's the case, in
particular when you are lazy, and I am a bit lazy, I admit to this ... ;P

But just to clarify! I agree with making the gems ecosystem more secure,
transparent and so forth. I just also would like for any trade-offs to be
discussed and considered; see older changes against typo-squattings
that also penalized perfectly "normal" devs too merely because they had
weird names for their gems.

[greysteil]

@rubyFeedback - the only time this will affect RubyGems authors is if their API key has been exposed in a public repo. In that case, that RubyGems API token is compromised, and anyone who finds it could push new, malicious versions of the author's gems, or yank existing versions. In both cases, it's not a great situation for the gem author.

Since the inconvenience for a gem author here is small (having to generate a new API token) and only happens in the case where their token has been compromised I think this is a worthwhile security tradeoff.