On Mon, May 26, 2025 at 6:03 PM Elijah Newren [off-list ref] wrote:

On Mon, May 26, 2025 at 3:33 AM Christian Couder
[off-list ref] wrote:

I'd like to propose that the following are the possible uses that
users might have regarding commit signatures with
fast-export/fast-import (if anyone has additional usecases, let me
know):

(A) Make fast-export include signatures, and make fast-import include
them unconditionally (even if invalid)
(B) Similar to (A), but make *fast-import* check them and either error
out or drop them if they become invalid
(C) Simliar to (B), but make *fast-import* re-sign the commit if they
become invalid
(D) Similar to (A), but make *fast-import* re-sign the commit even if
the signature would have been valid

Note that in the above, there might be additional processing between
when fast-export runs and when fast-import does (e.g. by filter-repo
or a similar tool, or even the user editing by hand).

I agree that they are likely to be the most important use cases, and I
am fine with working on these use cases.

quoted

To address this, I decided to focus first on extracting the hash
algorithm from OpenPGP/X.509 signatures and the key type from SSH
signature when checking signatures.

To test that, I thought that it could be interesting to add a
`--summary` option to `verify-commit` that shows a concise, one-line
summary of the signature verification to standard output in the
`STATUS FORMAT ALGORITHM` format, where:

* STATUS is the result character (e.g., G, B, E, U, N, ...), similar
  as what the "%G?" pretty format specifier shows,

* FORMAT is the signature format (`openpgp`, `x509`, or `ssh`),

* ALGORITHM is the hash algorithm used for GPG/GPGSM signatures
  (e.g. `sha1`, `sha256`, ...), or the key type for SSH signatures
  (`RSA`, `ECDSA`, `ED25519`, ...).

This sounds like it might be a nice feature extension to the
verify-commit builtin.  I don't see how it helps implement signature
handling in fast-export/fast-import, though.

Fair enough. In the v3 and v4, I changed the approach and dropped all of this.

quoted

If we can agree on a concise format output for signature checks, then
maybe this format will be a good format to be used in the `git
fast-export` output for users who are fine with signatures being
checked.

What do you think?

Maybe I'm missing something, but it seems to me that checking
signatures *in fast-export* would be a complete waste of time.  For
usecases (A) & (D), checking signatures at all is a waste of time.
For usecases (B) & (C), checking signatures in fast-export is
throwaway work because whether or not the signatures are valid at the
time fast-export runs, and even in the rare usecase where there is no
additional processing between fast-export and fast-import (such as by
filter-repo), the signatures would still need to be re-checked by
fast-import anyway.  (Note that a simple `git fast-export ... | git
fast-import` is *not* guaranteed to get the same commit hashes even
when there are no commit signatures; that only happens when the
history is sufficiently canonical).

Yeah, right. In v3 and v4, I dropped this in favor of something
simpler similar to what was in the v1 patch, and after that I plan to
work on checking signatures in fast-import soon. Thanks.