Re: Preserving the ability to have both SHA1 and SHA256 signatures

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: May 9, 2021, 00:19 UTC
Message-ID: <YJcqqYsOerijsxRQ@camp.crustytoothpaste.net>
In-Reply-To: <20210508022225.GH3986@localhost>

On 2021-05-08 at 02:22:25, dwh@linuxprogrammer.org wrote:

Show 18 quoted lines

> Hi Everybody,
> 
> I was reading through the
> Documentation/technical/hash-function-transition.txt doc and realized
> that the plan is to support allowing BOTH SHA1 and SHA256 signatures to
> exist in a single object:
> 
> > Signed Commits
> > 1. using SHA-1 only, as in existing signed commit objects
> > 2. using both SHA-1 and SHA-256, by using both gpgsig-sha256 and gpgsig
> >   fields.
> > 3. using only SHA-256, by only using the gpgsig-sha256 field.
> > 
> > Signed Tags
> > 1. using SHA-1 only, as in existing signed tag objects
> > 2. using both SHA-1 and SHA-256, by using gpgsig-sha256 and an in-body
> >   signature.
> > 3. using only SHA-256, by only using the gpgsig-sha256 field.

Yes, this is the case.  We have tests for this case.

Show 6 quoted lines

> The design that I'm working on only supports a single signature that
> uses a combination of fields: one 'signtype', zero or more 'signoption'
> and one 'sign' in objects. I am thinking that the best thing to do is
> replace the gpgsig-sha256 fields in objects and allow old gpgsig (commits)
> and in-body (tags) signatures to co-exist along side to give the same
> functionality.

You can't do that. SHA-256 repositories already exist and that would break compatibility.

> That not only paves the way forward but preserves the full backward
> compatibility that is one of my top requirements.

I've reviewed your proposed design and provided feedback that we need to preserve this functionality in your new design as well. People will want to have that functionality.

-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US