On 2021-05-08 at 02:22:25, dwh@linuxprogrammer.org wrote:
> 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.

> 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