Support GitHub Secret Scanning

[houllette]

Changes in this PR are in order to support the Secrets Scanning Partner Program from GitHub.

The most notable change found within is that newly generated user_secrets will now prepend hexpm_ to the base16 encoded strings. e.g. hexpm_316e6532776f3368726565

Other changes are just to support the GitHub webhooks for the Secret Scanning flow.

[ericmj]

Hi @houllette! Are you interested in picking up this PR again?

[houllette]

Hey! I would love to contribute to this more, but I cannot confirm when/if I have the time at the moment - if there is some desire to get this work going by someone else; by all means run with it! I'll be happy just to have been able to cast some light on the feature add 🙂

[supersimple]

Note for continued work on this feature:

Once we've committed to this pattern for keys, we need to email github with the pattern

[supersimple]

The regexp to submit, based on the code in this PR is: /^hexpm_[0-9a-f]{32}$/

[supersimple]

hi @houllette - I moved (and continued work) in a different branch that is committed to this repo supersimple/github-secret-scanning
If you want to continue work, let's use that branch since we can both contribute.
I have done my best to leave notes on the parts that are WIP, but also ask questions here if you have any.

Thanks

[ericmj]

We are considering using JWTs for some tokens in the future. Are these compatible with the secret scanning program since they do not allow adding a prefix such as hexpm_ without breaking the spec afaict?

[supersimple]

We are considering using JWTs for some tokens in the future. Are these compatible with the secret scanning program since they do not allow adding a prefix such as hexpm_ without breaking the spec afaict?

well, yes. JWTs couldn't use a prefix. Also, one reason to use JWTs are their short TTLs, so I don't think the GH secret scanning would be of much help.

[houllette]

@ericmj could you help me understand the intended usage of JWTs in the future? While they would have a shorter TTL in the event of a leakage - unfortunately they would still be usable until that point.

I've had to go down the path of revoking JWTs before and it's not a particularly fun one, but it depends on the use case.

[ericmj]

We want to use JWTs to be able to do authentication at the edge/CDN. Right now every request for a private package also hits our API which is bad for scaling reasons. A possible solution for this would be to hit the API once to generate a JWT and use that for later repository/package requests.

Users may want to move this JWT around depending on their CI setup which could leak it in output but it's probably unlikely it would be committed to a repo.