Beyond Identity: Handle signatures created by re-added GPG key
Overview
When a user has a GPG key uploaded, creates a commit signed by the key and the commit gets rejected, the signature is still created and cached.
If the user then re-adds the GPG key, i.e removes it from GitLab and then adds it again, a new database record is created: however, the existing signatures will still point to the deleted one.
When a user tries to push the same commit again, the cached signature is fetched, but the GPG key is missing for it. The commit is rejected as a result.
Proposal
There are multiple options:
- Clean-up the cached signature if the commit is rejected or re-create it if
gpg_key_id
isnil
- Fetch the GPG key using
gpg_key_primary_keyid
of the signature instead of relying ofgpg_key_id
- The GPG signature stores
gpg_key_primary_keyid
,gpg_key_user_name
,gpg_key_user_email
and we may want to use this data instead of fetch the GPG key, but we probably shouldn't do it because we need to check that the associated key still exists at GitLab