Why don’t git servers (gitlab, github, etc…) allow for a whitelist of public GPG keys allowed to sign commits? For example, Alice owns a GPG key with fingerprint 0A1B2C3D while Bob’s is 4E5F0A0B. They work together and they pass their key’s fingerprint to the git server admin and those fingerprints are added to the server’s whitelist. In that case, if an attacker were to compromise Alice’s or Bob’s laptop, they cannot push any backdoor to the code, since they protected their private keys with a strong passphrase and servers reject unsigned commits.

However, enforcing signed commits rather than enforcing commits signed by a trusted key means the attacker can create a new key pair on Alice’s or Bob’s laptop, using their name and email, add it to the git server and then push a commit with a backdoor (since servers typically verify that the committer email matches one email in the list of the key’s UID and that it matches the server’s registered email). This of course assumes a series of hypothesis (compromised laptop, ability to add GPG keys on the server,…)

For me, it’s certainly not too far-fetched if someone leaves their laptop unattended, for example (we all know an Alice or Bob who doesn’t lock their laptop while going for a coffee or to the bathroom)

Does this seem far-fetched enough for git server providers not to add this option?

Am I missing something here?

1 Answer 1


I can't speak for other implementations, but GitHub does require that the key used for a signed commit be one of the ones associated with the account in order to consider the commit verified. Additional keys are not suitable for that purpose, if for no other reason than that GitHub doesn't have them and won't fetch them from an external source.

If you enable the feature to require signed commits, the commits must be verified, which means that the signature must match the key associated with account which is linked to the committer's email address.

  • I believe most major gitservers require that the signing key be added beforehand, but I can't avoid thinking that a compromise in the local machine may imply a compromise in the user's gitserver account, which may imply that the attacker can add whatever key they want and associate it to the committer's email (that information is known by looking git log for instance)
    – mrbolichi
    Commented Sep 8, 2021 at 6:39
  • @mrbolichi Adding a key requires the user to enter "sudo" mode on GitHub which requires re-authenticating, so the attacker would at least need to know the victim's password, be able to reset it, or have access to their Yubikey.
    – Ritchie
    Commented Sep 15, 2022 at 0:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .