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