If I sign a git commit with an OpenPGP key that has an expiration date, what does that mean for people looking at that commit after the expiration date? Should all keys used for commit signing like this be permanent?
What if the verifying party have a new key from me? Or just my old? Or both?
I'm new to OpenPGP in general, especially in relation to signing git commits.
OpenPGP's expiration date only indicates "this key should not be used after a given date", but does not render a key useless: the math still works fine.
If I sign a Git commit with a PGP key that has an expiration date, what does that mean for people looking at that commit after the expiration date?
When verifying signatures, OpenPGP implementations will compare the expiry date with the date the signature was issued. If the signature was issued within the expiration period, you're fine. If not, it will issue a warning (something like "the signature was fine, but issued after expiration).
What if the verifying party have a new key from me? Or just my old? Or both?
If they have your old key, they can verify signatures issued by your old key. For your new key, they can verify those issued by your new key. If they have both, they can verify both.
Should all keys used for commit signing like this be permanent?
Be aware that the expiration date does not really add up any security, as it can be changed arbitrarily as long as you have control over the secret primary key. Also, the signature date can be set arbitrarily, it is written by the OpenPGP implementation used for creating the signature; an attacker might just set a faked system time. I discussed the security of the expiration date in detail on the Information Security sister site in the question "Does OpenPGP key expiration add to security?".
Using an expiry date is fine if you want to indicate the key will not be used after a given time, but do not consider it a security feature. Lots of people with advanced OpenPGP key usage have a primary key with no expiry date and regularly escrow subkeys, which they issue with a limited validity period.
Creating new primary keys means others must validate your new key again. The primary key is the common trust anchor in OpenPGP, and creating a new one means losing all trust/certifications.
You can and should still use expiring keys.
The idea of this system is that keys expire and you generate new ones. But in the PGP world you upload your keys to keyservers. They essentially work like a phone book (*) so everyone wanting to retrieve your public key to send you an encrypted message will be able to get access to it. And that is also the solution to your problem. The keyserver will still remember expired keys so your signature stays valid although expired (validation only depends on a correctly applied signature with a once valid key). Your users will see that when validating your signature for which they retrieved the key you used for this particular signature. But as you go along developing and releasing signed versions you will always sign with valid keys and people just keep retrieving your new ones.
(*) The comparison of a keyserver with a phonebook simplifies the situation but lacks one important portion of information: If you use a keyserver to retrieve a key of a person that is unknown to you keep in mind that this key may be compromised. E.g. Alice wants to communicate with Bob utilizing encryption (or just verify a git commit of Bob's) but she does not know him. She takes Bobs public key from a remote server but is not aware of the fact that Mallory forged it and placed it there. So the verification process is compromised and she will not notice. The way out: Bob can publish the fingerprints of his public key (or the key, too) together with the software that he signed on his website. Alice can now take a key, compare its fingerprint to the one Bob provided in order to verify she has Bob's genuine public key. With that she can now verify his signed commit on git. This also works if the key is expired.
git show-signature/verify considers revoked keys to be invalid even if signed before the key was revoked, see this example from a revoked yubikey signature: https://www.flickr.com/photos/steve_l/37493124630/in/datetaken/
Given this outcome, I think it may be less traumatic to not revoke a key in such situations, but change the expiry date and push up an update to the keyservers saying "The key is expired". This way, existing commits are still validated.
