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
Junio C Hamano <gitster@pobox.com>
Date
Sep 20, 2025, 17:04 UTC
Message-ID
<xmqqms6pxdg4.fsf@gitster.g>
In-Reply-To
<aM7IQibwwKFJZcYE@fruit.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 23 quoted lines
> On 2025-09-19 at 22:34:02, Junio C Hamano wrote:
>> "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?
Let me see if I got it right by trying to paraphrase the above.

For any object that is suitable to be stored in a repository with objectFormat and compatObjectFormat set, "current" is the former, and "the other" is the latter.

Your goal is not educating me, though. I wanted to make sure that the text would be understood by the target audience of this document in a way you intended it to be.

Thanks.
Previous: brian m. carlsonNext: Patrick Steinhardt
Message 5 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.