So I’ve accidentally revoked my GPG key https://gitlab.com/help/user/project/repository/gpg_signed_commits/index.md#revoking-a-gpg-key is it possible to revert it? I want my commits to be shown as verified 
I have this problem as well 
I have tried re-adding the previously revoked key which Gitlab imports without any issues, new commits are signed and shown as “verified”, but all historical commits are still marked “unverified”. Did you find a resolution to this?
Historical commits will always show as “unverified” if:
- Commits were made without using a GPG key.
- Commits were made using a GPG key, but the GPG key wasn’t imported into Gitlab when the commit was made.
- GPG key was added to Gitlab, but the commit was not signed with the GPG key.
You cannot change previous commits made under the above scenarios/situations. Only new commits made once the GPG key has been added to Gitlab, and when the commits are being signed will show as verified.
Thanks for the answer. Yeah to be clear these commits had been verified, I accidentally clicked “Revoke” instead of the (greyed out) trash can icon and confirmed, this then marked all previously verified commits as “unverified”. I had a backup of the original GPG key which I then re-imported, and new commits using the same key ID are shown as verified, but the historical ones are all “unverified” even though I have now re-imported the same key and can sign with it etc.
There is an issue where someone has brought up this situation: Incorrect GPG signature status if (sub)key was revoked (#255279) · Issues · GitLab.org / GitLab · GitLab
This issue also shows the popup on revoke that it will change them to unverified: Two main calls to action for removing/revoking GPG key (#28347) · Issues · GitLab.org / GitLab · GitLab
Not sure what Gitlab’s view is on this on whether they should be unverified or whether they plan to change it. Reasoning is given in the first issue linked.
Yeah those definitely look related. It seems like “revoke” is treated as “compromised” in all cases, along with arguably a UX for managing GPG keys that could be much clearer about the consequences of accidentally choosing “revoke” vs “delete”. Looks like Github already had similar situation previously and updated their behaviour Improved verification of historic Git commit signatures - The GitHub Blog.
My two cents I feel like if you restore a previously revoked key, so long as it is valid, then that should restore any commits that had been marked unverified.
I guess I will have to put this down to a user error situation though, however I really hope they will improve this in future.
1 Like
Actually it is all looking good again in my case! A few hours after I re-imported the GPG key the verified statuses all got restored across all existing commits. I am guessing there must be a periodic/cron job that run and updated them all. Extremely happy to see this, and hope the original poster might be able to use a similar solution, if they have a back-up of the original key they can re-import.
1 Like
There are a load of cronjobs in sidekiq, so could be that one of them sorted it out. So it worked out well for you in the end 