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

Re: [PATCH 3/9] docs: reflect actual double signature for tags

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Sep 20, 2025, 15:29 UTC
Message-ID
<aM7IQibwwKFJZcYE@fruit.crustytoothpaste.net>
In-Reply-To
<xmqq348i138l.fsf@gitster.g>
On 2025-09-19 at 22:34:02, Junio C Hamano wrote:
Show 14 quoted lines
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> >  Signed Tags
> >  ~~~~~~~~~~~
> > +We add new fields "gpgsig" and "gpgsig-sha256" to the tag object format to
> > +allow signing tags in both formats.  The in-body signature is used for the
> > +signature in the current hash algorithm and the header is used for the
> > +signature in the other algorithm.  Thus, a dual-signature tag will contain both
> 
> Not suggesting a change in the text, but to make sure I am reading
> the new text correctly.  Does "the other algorithm" refer to the
> compatibility hash algorithm specified by the compatObjectFormat
> extension and the "current" algorithm refers to the objectFormat
> extension?

The "current algorithm" is usually the main algorithm (that is, SHA-256 where `extensions.objectformat` is `sha256`) and the "other algorithm" is the compatibility algorithm (SHA-1 in that case). However, when you convert that object to SHA-1 to hash it in SHA-1, the "current algorithm" becomes SHA-1 and the "other algorithm" is SHA-256.

Does that make sense?
Show 10 quoted lines
> > +an in-body signature and a gpgsig-sha256 header for the SHA-1 format of an
> > +object or both an in-body signature and a gpgsig header for the SHA-256 format
> > +of and object.
> >  
> > -This means tags can be signed
> > +The signed payload of the tag is the content of the tag in the current
> > +algorithm with both its gpgsig and gpgsig-sha256 fields and
> 
> My reading of the previous paragraph is that we cannot have gpgsig
> and gpgsig-sha256 fields on a single object at the same time.

Correct, unless we come up with a third hash algorithm. Hopefully that is a long way away, and we are not considering that case here.

Show 10 quoted lines
> Should we say "gpgsig or gpgsig-sha256" (instead of "and"), to get
> the resulting text parsable as:
> 
> 	both 
> 		its gpgsig or gpgsig-sha256 fields
> 	and
> 		"-----BEGIN PGP SIGNATURE-----" delimited in-body signature
> 	removed.
> 
> instead?
Sure, I'll include that in a reroll.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA
Previous: Junio C HamanoNext: Junio C Hamano
Message 4 of 67 in “SHA-1/SHA-256 interoperability, part 1”
  1. 0/9 SHA-1/SHA-256 interoperability, part 1brian m. carlson, Sep 19, 2025
  2. 3/9 docs: reflect actual double signature for tagsbrian m. carlson, Sep 19, 2025
  3. Junio C HamanoSep 19, 2025
  4. brian m. carlsonSep 20, 2025
  5. Junio C HamanoSep 20, 2025
  6. Patrick SteinhardtSep 24, 2025
  7. brian m. carlsonSep 25, 2025
  8. 1/9 docs: update pack index v3 formatbrian m. carlson, Sep 19, 2025
  9. Junio C HamanoSep 19, 2025
  10. brian m. carlsonSep 20, 2025
  11. Junio C HamanoSep 20, 2025
  12. Patrick SteinhardtSep 24, 2025
  13. brian m. carlsonSep 25, 2025
  14. 2/9 docs: update offset order for pack index v3brian m. carlson, Sep 19, 2025
  15. 4/9 docs: improve ambiguous areas of pack format documentationbrian m. carlson, Sep 19, 2025
  16. Junio C HamanoSep 19, 2025
  17. 8/9 Allow specifying compatibility hashbrian m. carlson, Sep 19, 2025
  18. Patrick SteinhardtSep 24, 2025
  19. brian m. carlsonSep 30, 2025
  20. 5/9 docs: add documentation for loose objectsbrian m. carlson, Sep 19, 2025
  21. Junio C HamanoSep 19, 2025
  22. Junio C HamanoSep 19, 2025
  23. brian m. carlsonSep 19, 2025
  24. Junio C HamanoSep 19, 2025
  25. Patrick SteinhardtSep 24, 2025
  26. brian m. carlsonSep 25, 2025
  27. Junio C HamanoSep 19, 2025
  28. Patrick SteinhardtSep 24, 2025
  29. brian m. carlsonSep 30, 2025
  30. 6/9 rev-parse: allow printing compatibility hashbrian m. carlson, Sep 19, 2025
  31. Junio C HamanoSep 19, 2025
  32. Patrick SteinhardtSep 24, 2025
  33. brian m. carlsonSep 25, 2025
  34. 7/9 fsck: consider gpgsig headers expected in tagsbrian m. carlson, Sep 19, 2025
  35. Junio C HamanoSep 19, 2025
  36. brian m. carlsonSep 22, 2025
  37. 9/9 t: add a prerequisite for a compatibility hashbrian m. carlson, Sep 19, 2025
  38. Patrick SteinhardtSep 24, 2025
  39. 0/9 SHA-1/SHA-256 interoperability, part 1brian m. carlson, Oct 2, 2025
  40. 1/9 docs: update pack index v3 formatbrian m. carlson, Oct 2, 2025
  41. Junio C HamanoOct 3, 2025
  42. 3/9 docs: reflect actual double signature for tagsbrian m. carlson, Oct 2, 2025
  43. 2/9 docs: update offset order for pack index v3brian m. carlson, Oct 2, 2025
  44. 4/9 docs: improve ambiguous areas of pack format documentationbrian m. carlson, Oct 2, 2025
  45. Junio C HamanoOct 3, 2025
  46. brian m. carlsonOct 3, 2025
  47. 5/9 docs: add documentation for loose objectsbrian m. carlson, Oct 2, 2025
  48. Junio C HamanoOct 3, 2025
  49. 7/9 fsck: consider gpgsig headers expected in tagsbrian m. carlson, Oct 2, 2025
  50. 6/9 rev-parse: allow printing compatibility hashbrian m. carlson, Oct 2, 2025
  51. 8/9 t: allow specifying compatibility hashbrian m. carlson, Oct 2, 2025
  52. Junio C HamanoOct 3, 2025
  53. brian m. carlsonOct 3, 2025
  54. 9/9 t1010: use BROKEN_OBJECTS prerequisitebrian m. carlson, Oct 2, 2025
  55. 0/9 SHA-1/SHA-256 interoperability, part 1brian m. carlson, Oct 9, 2025
  56. 3/9 docs: reflect actual double signature for tagsbrian m. carlson, Oct 9, 2025
  57. 4/9 docs: improve ambiguous areas of pack format documentationbrian m. carlson, Oct 9, 2025
  58. 2/9 docs: update offset order for pack index v3brian m. carlson, Oct 9, 2025
  59. 1/9 docs: update pack index v3 formatbrian m. carlson, Oct 9, 2025
  60. 5/9 docs: add documentation for loose objectsbrian m. carlson, Oct 9, 2025
  61. 6/9 rev-parse: allow printing compatibility hashbrian m. carlson, Oct 9, 2025
  62. 8/9 t: allow specifying compatibility hashbrian m. carlson, Oct 9, 2025
  63. 7/9 fsck: consider gpgsig headers expected in tagsbrian m. carlson, Oct 9, 2025
  64. 9/9 t1010: use BROKEN_OBJECTS prerequisitebrian m. carlson, Oct 9, 2025
  65. Junio C HamanoOct 13, 2025
  66. brian m. carlsonOct 13, 2025
  67. Patrick SteinhardtOct 14, 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.