Umgang mit signierten Git-Commits mit widerrufenem GPG-Schlüssel

Question

Ich habe mit dem GPG-Schlüssel "A" eine Zeit lang Git-Commits unterschrieben. Nach einer Weile beschloss ich, diesen Schlüssel zu entziehen und den GPG-Schlüssel "B" zu verwenden. Ich habe auch weiterhin neue Git-Commits mit Schlüssel "B" signiert.

Ich habe immer noch beide Schlüssel (den widerrufenen Schlüssel "A" und neuen Schlüssel "B") lokal. Neue Commits sind in Ordnung, aber das Problem, das ich jetzt habe, ist, dass alle alten Git-Commits, die mit dem widerrufenen Schlüssel "A" signiert sind, mit roter Warnung angezeigt werden, wenn sie mit git log --show-signature angesehen werden.

Hier ist, wie diese Warnung in git log sieht (das meiste davon ist rot schreiend):

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 

Gibt es eine Einstellung, die ich git oder GPG sagen kann, dass dieser Schlüssel noch „ok“ und Vertrauen-able Es ist nur so, dass ich es nicht mehr benutze? (Ich möchte diesen alten Schlüssel aufgehoben haben)

Ich würde mich freuen, wenn gpg (oder git) "mild" angibt, dass der Schlüssel nicht verwendet wird, anstatt gefälschte Commits vorzuschlagen. Gibt es eine Sicherheits- oder Vertrauensstellung, die ich einstellen könnte, um dies zu erreichen?

Answer 1

-Update Q4 2016 mit Git 2.11:

git log führt zusätzlichen Statuscodes E, X, Y, R für ERRSIG, EXPSIG, EXPKEYSIG und REVKEYSIG, so dass ein Benutzer von %G? mehr Informationen bekommt.
Siehe Verifying signed git commits?

---

Es gibt nicht viel scheint in Ihrem Fall zu tun.

Das was debated in 2010, darunter eine interessante Idee als Best Practice:

Sie können natürlich mehr als eine E-Mail-Adresse pro Taste, aber Sie sollten nie mehr als einen Schlüssel per E-Mail.

Dies ist eigentlich ziemlich häufig.
Zumindest wird es passieren, wenn Leute versuchen, zwischen einem älteren und einem neueren Schlüssel zu wechseln - zum Beispiel, wenn sie versuchen, von einem weniger sicheren Kryptoalgorithmus zu einem sichereren Kryptoalgorithmus zu wechseln.

Wie ich die Dinge die beste Art und Weise verstehen, diese Art von Dingen zu verwalten, ist Unterschlüssel zu verwenden. Sie können die Ablaufzeit für einen Unterschlüssel ändern, und dann schließlich können Sie es widerrufen, während Sie Ihren einen primären öffentlichen Schlüssel zum Signieren erhalten.
In der Tat ist es eine gute Idee, regelmäßig Ihre Sub-Taste zu ändern und die älteren ablaufen.

Sehen Sie, wenn Sie subkeys (nach etwa this tutorial oder this one) verwenden können:

OpenPGP weiteren Stützen Subkeys, die wie die normalen Tasten sind, außer sie zu einem Master-Schlüsselpaar gebunden sind. Ein Unterschlüssel kann zum Signieren oder zur Verschlüsselung verwendet werden.
Der wirklich nützliche Teil von Unterschlüsseln ist, dass sie unabhängig von den Hauptschlüsseln widerrufen werden können und auch getrennt von ihnen gespeichert werden können.