The trick is to consider the key invalid for use in signing after it expires, but still valid for verification after that time. Signatures produced by that key can be considered valid well after the key itself has expired. For that to work, you need to have some confidence that the signature was produced at a given time, which is what third-party time stamping authorities (TSA) do. You send your signature to a TSA, which validates the signature, and that the key is valid at the current time, and the TSA counter signs.

For a large project with multiple contributors I wouldn't want to sign the whole tree at a particular point in time (which seems like the natural interpretation of a signed tag) unless I'd actually reviewed it all personally (which, sure, maybe some maintainers do). The commit is the part that I made, so that's the part that I want to sign (and of course it contains a secure reference to a parent commit, but a reader would naturally understand that I'm not vouching for the whole repo history). And I'd far rather publish my contributions as commits on my branches (that then become a PR) than email patches around and worry about how to archive that, personally.

The problem is that your signature is associated to the commit so it does make you vouch for history, and it lives on after your PR is merged. If you're doing a PR there's a chance that you are authenticated so that is what guarantees the changes do come from you and are not modified (your PR software should log all changes to the PR). Worst case your PR itself can be PGP-signed to say "I would like branch XXX currently at commit YYY be merged onto master currently at ZZZ" but I totally agree it would be a heavy process and signing commits does the job

> The problem is that your signature is associated to the commit so it does make you vouch for history, and it lives on after your PR is merged.

That's exactly what I want though. I want anyone looking through history to be able to see that I signed that specific diff in that context (something weaker than the whole state of the tree at that point in time - but something stronger than the textual diff with no other context). The fact that rewriting history will break the signature is a feature not a bug, but I'd like the patch to carry my signature even after it's merged.

I'm casually learning about this stuff, so please forgive my noob questions. My end-goal is to enable laypersons like me to verify the authenticity and provenance of digital communication.

I see that Ryabitsev also announced a git transparency log for the kernel:

https://people.kernel.org/monsieuricon/introducing-the-kerne...

This is very cool.

You wrote:

> ...it is valid at most until the key is valid

I don't follow. Do you mean while the key is valid?

I think the scenario you're describing is:

  a) I'm issued a cert. 
  b) I create (and register) my PGP key. 
  c) I sign a commit with my key. 
  d) My cert is revoked. 
  e) Somehow my key is expired. 
  f) Somehow my commits are now flagged.

Would your concern be addressed by having transparency logs for both the certs and keys?

Sorry I did mean valid while the key is valid, of course.

The scenario I'm describing is simpler:

- You create a PGP key

- You sign a commit with that key

- The key expires (you definitely should have a key rotation process in-place, so keys should expire)

- I want to use your commit. I see it is signed but the key is expired. What is the value of the signature at this moment ?

When a key is expired your commits don't automatically become bad, they just become "unverifiable" but you can't resign them without changing their hash; that's why signing tags is better because you can re-sign tags quickly (before the key is expired).

> Would your concern be addressed by having transparency logs for both the certs and keys?

Transparency logs only catch the problem after they appear and raise the chance that they are detected but they don't prevent it from happening. If we're talking about making sure no one changes your patches/commits under your feets, a transparency log of commits is "enough", and that's basically what the git repository is all about.

Why is this a problem, the key was valid however at the time the commit was made?

> https://lwn.net/Articles/813646/

Huh? Replace one convoluted process for another convoluted and less capable one? Seems like not invented here syndrome. Not surprised it's not used. If you're using email for critical, sensitive work, spend the 15 minutes to learn how PGP works and another to set it up. You can even sign your git commits and tags with them!

Also, get some yubikeys, they work well with pgp.

I think you need 15 minutes to understand what the problem is about. An email-based workflow like the one the linux tree uses is based on patches, not commits. You may want to sign commits but it will be useless because commits aren't exchanged. So the proposed process doesn't "replace" anything: there's no signing in the first place.

You can't sign patches directly because then they wouldn't be usable by the git tools like git-am. So you need a meta data-structure that contains all patches and relevant information kinda like a pseudo-commit: the author, message and patch itself. Then that meta data-structure can be pgp-encrypted and sent by email, as described by your link and as you implied was not done

> Why is this a problem, the key was valid however at the time the commit was made?

You want to check the validity of a commit at the moment you use it, not the moment the commit was made: imagine I put up a fake tree, with a fake commit with you as an author but made with a fake key that already expired. What's the use of that signature ? Can a third-party cherry-pick that commit and trusting that "the key was valid at the time the commit was made" ? You can sign that you did something at some point but you can't sign that you never did something, or that you never used a given key.

> spend the 15 minutes to learn how PGP works and another to set it up

You can't seriously believe that it takes 15 minutes to understand how PGP works and 15 minutes to set up a functional environment and expect it to follow the best standards. Even reading the kernel's documentation on how to use pgp (https://www.kernel.org/doc/html/v5.1/process/maintainer-pgp-...) takes more than 15 minutes.

> Also, get some yubikeys, they work well with pgp.

I don't understand what's the link with the rest of the discussion

> You want to check the validity of a commit at the moment you use it, not the moment the commit was made

If you received the repo before the key expired, you can still trust the signature even if the key has since expired, as the key was valid at that time the repo was signed.

> imagine I put up a fake tree, with a fake commit with you as an author but made with a fake key that already expired

Yes, you cant trust a key after after it's expiration. See bottom of https://www.kernel.org/signature.html for how the kernel.org folks handled this in 2011. Once they re-signed the release, it's safe to trust the compromised key within that release.

> I don't understand what's the link with the rest of the discussion

We're discussing complexity of pgp adoption, security cards simplify the usage of pgp, thought it was relevant.

I'm thinking more like the recent PHP repository compromise. I was thinking at some point that I may want to host my own git public repos, but they might not be safe. My solution could be to ask people to check my signatures.

I haven't read a lot about that issue but if I understand correctly a malicious actor had write access to the repo, and yes signing tags could have prevented this push to be problematic (I don't know if they're signing content or not). It's always good to check signatures especially when we have the tools to do that automatically

> keys expire

Only if you want them to expire. They don't have to.

Given enough time, every secret becomes public. You really shouldn't expect your keys to be secure forever; because of that you definitely should have a form of key rotation in place.

A key can be involuntarily "expired" if the private key was leaked.

That's revocation.