Don't rely on just a single Github account's security

[bloodearnest]

Currently, if a developer's GH is compromised (incl. 2fa, so not trivial, but still) then an attacker can update the compromised user's key to one they control, and thus log in everywhere.

If they can add a new account, then they'd have root everywhere too, as they'd be able to set a password.

Our branch protection rules of 2 reviewers mitigate this threat for some of the team, but for those with admin access (7 people currently) to this repo, then the attacker can disable branch protection.

So it would be nice to require compromising more that just one GH account to gain accesss.

Ideas:

1. In terms of creating new accounts, we could possibly try verify the user against our Google Workspace organisation, requiring they are a member of a specific group their. This would require credentials of some kind to be deployed with kissh though, as there is not public read-only way to check for google group membership that I can find.

2. Another tools is the fact we sign commits. However, the obvious source of the correct key to check with is GH, so a compromised account doesn't help us there either, as the attack could just update the key in the compromised user's account. We could possibly do a web of trust for this, perhaps. Or validate the GH key against an external keyserver also before trusting it, which would require our developers to upload their key there.

3. Another possible option is to require another GH user to sign off the commit with their key for it to be trusted. That would up the bar to 2 separate GH accounts compromised. Don't think this is possible via the Github UI, but should be doable via scripting in the cli (e.g. annotated tags)

I'm not sure what the cost/benefit of all this is. Maybe what we have is good enough. Just wanted to dump some thoughts while it was fresh in my mind.