Signed git processing terminates with revoked GPG key

I signed git fixes for a while using the GPG key "A". After some time, I decided to revoke this key and start using the GPG key "B". I also continued to sign a new git with the key "B".

I still save both keys (revoked key "A" and new key "B") locally. The new commits are fine, but the problem I'm currently facing is that all old git commits signed with the canceled key "A" are displayed with a red warning when viewed using git log --show-signature .

Here's how this warning looks in the git log (most of it shouts in red):

 commit 39a53e42c8856278f481b9035e54eb90d8d2a0b7 gpg: Signature made Sat Aug 1 22:24:38 2015 CEST using RSA key ID 2F7EF26C gpg: Good signature from "My Name <email1>" [ultimate] gpg: aka "My Name <email2>" [ultimate] gpg: WARNING: This key has been revoked by its owner! gpg: This could mean that the signature is forged. gpg: reason for revocation: Key is superseded gpg: revocation comment: New GPG key is used. gpg: revocation comment: New key fingerprint: C464 17C1 4F7B D54E A082 7090 CAFA 7B1B 2914 ED81 gpg: revocation comment: New key id: 2914ED81 Author: My name <email1> Date: Sat Aug 1 22:24:38 2015 +0200 Improve test helper 

Is there a parameter that I can tell git or gpg that this key is still โ€œgoodโ€ and trusting, I just donโ€™t use it anymore? (I want to leave this old key canceled)

I would appreciate it if gpg (or git) "softly" indicated that the key is not used, and does not offer fake commits. Are there any security or trust settings that I could set for this?

+5
source share
1 answer

Update Q4 2016 with Git 2.11:

git log introduces additional status codes E , X , Y , R for ERRSIG , EXPSIG , EXPKEYSIG and REVKEYSIG , so what is the user %G? receives additional information.
See Confirmation of Signed Git Commit?


In your case, you have nothing to do.

What was discussed in 2010, including an interesting idea as best practice:

Of course, you can have more than one email address for each key, but you should NEVER have more than one email key.

This is pretty common indeed. At least this will happen if people try to switch between the old and newer keys - for example, if they try to switch from a less secure cryptographic algorithm to a more secure cryptographic algorithm.

As I understand it, the best way to manage such things is to use sub-keys. You can change the expiration time of the sub-key, and then in the end you can revoke it, while maintaining one public key for signing .
In fact, it is a good idea to regularly change your turnkey and finish the old ones.

See if you can use subkeys (like this tutorial or this one ):

OpenPGP also supports subkeys that look like regular keys, except that they are bound to a master key pair. A subclass can be used for signature or for encryption.
The really useful part of the subsection is that they can be canceled independently of the main keys, and also stored separately from them.

+3
source

Source: https://habr.com/ru/post/1247574/


All Articles