git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Elijah Newren <newren@gmail.com>
Date
May 26, 2025, 16:03 UTC
Message-ID
<CABPp-BFbF=rp6FZjyL+Fm5TqNZZdhfjS1sK-CBQ_=wtvFmfdLw@mail.gmail.com>
In-Reply-To
<20250526103314.1542316-1-christian.couder@gmail.com>

On Mon, May 26, 2025 at 3:33 AM Christian Couder <christian.couder@gmail.com> wrote:

Show 41 quoted lines
>
> 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@gmail.com/
>
> 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).

Show 17 quoted lines
> 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.

Show 6 quoted lines
> 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).

Previous: Christian CouderNext: Christian Couder
Message 28 of 65 in “fast-(import|export): improve on the signature algorithm name”
  1. fast-(import|export): improve on the signature algorithm nameChristian Couder, Apr 24, 2025
  2. Junio C HamanoApr 24, 2025
  3. Elijah NewrenApr 24, 2025
  4. Junio C HamanoApr 24, 2025
  5. Christian CouderMay 26, 2025
  6. Junio C HamanoMay 27, 2025
  7. Junio C HamanoMay 28, 2025
  8. Elijah NewrenMay 28, 2025
  9. Junio C HamanoMay 28, 2025
  10. Elijah NewrenMay 28, 2025
  11. Junio C HamanoMay 29, 2025
  12. Christian CouderJun 2, 2025
  13. Christian CouderJun 2, 2025
  14. Junio C HamanoJun 2, 2025
  15. Christian CouderMay 26, 2025
  16. Elijah NewrenApr 24, 2025
  17. Christian CouderMay 26, 2025
  18. brian m. carlsonApr 24, 2025
  19. Christian CouderMay 26, 2025
  20. Junio C HamanoApr 24, 2025
  21. 0/6 extract algo information from signaturesChristian Couder, May 26, 2025
  22. 1/6 gpg-interface: simplify ssh fingerprint parsingChristian Couder, May 26, 2025
  23. 2/6 gpg-interface: use left shift to define GPG_VERIFY_*Christian Couder, May 26, 2025
  24. 3/6 doc/verify-commit: update and improve the whole docChristian Couder, May 26, 2025
  25. 4/6 gpg-interface: extract hash algorithm from signature status outputChristian Couder, May 26, 2025
  26. 5/6 gpg-interface: extract SSH key type from signature status outputChristian Couder, May 26, 2025
  27. 6/6 verify-commit: add a --summary flagChristian Couder, May 26, 2025
  28. Elijah NewrenMay 26, 2025
  29. Christian CouderJun 19, 2025
  30. brian m. carlsonJun 2, 2025
  31. Christian CouderJun 19, 2025
  32. fast-(import|export): improve on commit signature output formatChristian Couder, Jun 18, 2025
  33. fast-(import|export): improve on commit signature output formatChristian Couder, Jun 19, 2025
  34. Junio C HamanoJun 19, 2025
  35. Christian CouderJul 8, 2025
  36. Elijah NewrenJun 19, 2025
  37. Christian CouderJun 20, 2025
  38. Junio C HamanoJun 20, 2025
  39. Christian CouderJul 8, 2025
  40. Elijah NewrenJun 26, 2025
  41. Christian CouderJul 8, 2025
  42. Junio C HamanoJul 7, 2025
  43. Christian CouderJul 8, 2025
  44. Junio C HamanoJul 8, 2025
  45. Patrick SteinhardtJul 8, 2025
  46. Christian CouderJul 8, 2025
  47. Junio C HamanoJul 8, 2025
  48. Christian CouderJul 9, 2025
  49. Junio C HamanoJul 9, 2025
  50. Patrick SteinhardtJul 10, 2025
  51. Christian CouderJul 10, 2025
  52. Junio C HamanoJul 10, 2025
  53. Christian CouderJul 8, 2025
  54. fast-(import|export): improve on commit signature output formatChristian Couder, Jul 8, 2025
  55. Junio C HamanoJul 8, 2025
  56. Elijah NewrenJul 8, 2025
  57. Junio C HamanoJul 9, 2025
  58. Elijah NewrenJul 9, 2025
  59. Christian CouderJul 9, 2025
  60. Christian CouderJul 9, 2025
  61. fast-(import|export): improve on commit signature output formatChristian Couder, Jul 9, 2025
  62. Junio C HamanoJul 9, 2025
  63. Elijah NewrenJul 14, 2025
  64. Junio C HamanoJul 14, 2025
  65. Christian CouderJul 25, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.