From: brian m. carlson Date: Thu, 25 Sep 2025 21:46:58 GMT Subject: Re: [PATCH 3/9] docs: reflect actual double signature for tags Message-ID: In-Reply-To: On 2025-09-24 at 07:55:39, Patrick Steinhardt wrote: > You mentioned a "missed patch" in the commit message. So is this design > here intentional or merely an oversight? The original design was to implement all SHA-256 signatures in the `gpgsig-sha256` header, but the patch to do that got dropped accidentally for 2.29, so we shipped without it. I decided to fix it in a compatible way for 2.30 using the design here so that users who had created SHA-256 tags with 2.29 would not have them be mistaken for signatures over the SHA-1 values of the tag by Git 2.30. I knew that people would try things out nearly immediately and that some people would use very old versions of Git from their LTS distro and did not want to risk making an incompatible change that would break the object format, even while things were marked experimental. > I'm mostly asking because it feels weird to me that an object shouldn't > have both fields. I would assume that it's easier to implement and > reason about if this signature always was a header, or multiple that is. > But I'm not familiar enough with the logic here to really judge, so I > assume that there are good reasons that I miss. We should not have both fields. In the SHA-256 version of the tag, the in-body signature is SHA-256 and there is optionally a `gpgsig` header for the SHA-1 version of the tag. When that tag is converted into SHA-1 format, the in-body signature moves to the `gpgsig-sha256` header and the one that was formerly in the `gpgsig` header is placed in body and that header is removed. So we will never have both unless we have an additional hash algorithm, say, SHA-3-512, where, when in SHA-3-512 format, the in-body signature is over SHA-3-512 and there may be both `gpgsig` and `gpgsig-sha256` headers. -- brian m. carlson (they/them) Toronto, Ontario, CA