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

From: "brian m. carlson" <[email-masked]>
Date: Thu, 25 Sep 2025 21:46:58 +0000

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