Re: [PATCH v2 0/6] extract algo information from signatures

[Christian Couder <christian.couder@gmail.com>]

On Mon, May 26, 2025 at 6:03 PM Elijah Newren <newren@gmail.com> wrote:
>
> On Mon, May 26, 2025 at 3:33 AM Christian Couder
> <christian.couder@gmail.com> 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.

> > 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.

> > 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.