On Mon, May 26, 2025 at 3:33 AM Christian Couder <christian.couder@xxxxxxxxx> wrote: > > Around one month ago, I sent a patch that tried to improve on how `git > fast-export` handled SSH and X.509 commit signatures: > > https://lore.kernel.org/git/20250424203904.909777-1-christian.couder@xxxxxxxxx/ > > This patch was showing a single string for the hash algorithm with the > following possible values: > > * "openpgp" for SHA-1 OpenPGP signatures, > > * "sha256" for SHA-256 OpenPGP signatures, > > * "x509" for X.509 (GPGSM) signatures, > > * "ssh", for SSH signatures, > > * "unknown" for signatures that can't be identified (a warning is > emitted). > > brian m. carlson however replied that it would be better to show two > pieces of information instead of one: one for the hash algorithm and > one for the protocol. > > I have tried to do that but there were a number of issues. First it > seems to be easier to extract information from signatures when > checking them. And if you check them, then it might be interesting to > show the result of the check. > > Also for SSH signatures, it's difficult and not so informative to get > the hash algorithm. That's because the hash algorithm is often > specified by the key type (like "RSA", "ECDSA", "Ed25519", ...). For > example "Ed25519" has SHA-512 integrated into its design, and "ECDSA" > and "RSA" are typically used with SHA-256. So for SSH signatures it > seems better to just show the key type and not the hash algorithm. > > In general I am not sure what users might want regarding commit > signatures when using fast-export. Some might not need much signature > information at all, and for them checking signatures might just slow > the export process for no benefit, while others might want more > signature information even at the expense of a slower export. 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). > 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. > 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).
