Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What happens to OpenPGP-signed git commits after key expiration?

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.

like image 498
Captain Man Avatar asked Jul 20 '16 17:07

Captain Man


People also ask

What happens when a PGP key expired?

PGP public keys can be used to encrypt files up to the day they expire. Once the key expires it can no longer be used to encrypt data. A private key will continue to decrypt data that was encrypted by that public key, even after the public key expires.

What is a signed commit?

Technically it merely means the holder of the corresponding private key signed the commit. In practice it can be inferred 1) the holder of said key is a person with some verifiable reputation, 2) that person has claimed authorship of the code, and 3) the code hasn't changed since they signed it.

Are git commits signed?

If you're interested in signing commits directly instead of just the tags, all you need to do is add a -S to your git commit command. To see and verify these signatures, there is also a --show-signature option to git log .


2 Answers

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.

like image 156
Jens Erat Avatar answered Oct 29 '22 16:10

Jens Erat


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.

Read here, here and especially here for more info.

like image 34
harmonica141 Avatar answered Oct 29 '22 16:10

harmonica141