[RFE] Teach hash-object to be able to choose signature types

[RFE] Teach hash-object to be able to choose signature types

[Randall S. Becker]

Hi All,

I do not know whether this would be a good enhancement or micro project for
someone (maybe me) to take on, but I'm wondering whether it might be a good
idea to provide an option to hash-object to select the signature being
computed. The use case begins when someone computes an object signature and
stores a pre-converted SHA1 value. Then the repository is changed over to
SHA256. When hash-object is next called, perhaps in a different clone or
some other "next" scenario, the new signature will be SHA256, if I
understand this correctly, and from the perspective of the someone in the
use case, the signature mismatches.

What I am proposing is an option like --signature-type=SHA1|SHA256 or
similar as an option to hash-object to allow the non-default signature to be
selected explicitly. This is not entirely trivial looking through the code
and presumably would require either teaching hash_object_file_literally or
having a separate method to do the alternate calculation.

Thoughts?
Regards,
Randall

-- Brief whoami:
 NonStop developer since approximately 211288444200000000
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

Re: [RFE] Teach hash-object to be able to choose signature types

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

On 2019-08-16 at 22:22:17, Randall S. Becker wrote:
> Hi All,
> 
> I do not know whether this would be a good enhancement or micro project for
> someone (maybe me) to take on, but I'm wondering whether it might be a good
> idea to provide an option to hash-object to select the signature being
> computed. The use case begins when someone computes an object signature and
> stores a pre-converted SHA1 value. Then the repository is changed over to
> SHA256. When hash-object is next called, perhaps in a different clone or
> some other "next" scenario, the new signature will be SHA256, if I
> understand this correctly, and from the perspective of the someone in the
> use case, the signature mismatches.
> 
> What I am proposing is an option like --signature-type=SHA1|SHA256 or
> similar as an option to hash-object to allow the non-default signature to be
> selected explicitly. This is not entirely trivial looking through the code
> and presumably would require either teaching hash_object_file_literally or
> having a separate method to do the alternate calculation.

I'm actually working on this right now, and you're right, it isn't
trivial. I'm definitely not opposed if someone else is interested in
picking it up or writing it; I don't believe my outstanding patches
(which will likely show up on the list this weekend now that 2.23 is
out) would affect it in any way.

I'll try to push up the work that I'm doing into my "transition-interop"
branch; it contains the work for literal hashing and a more significant
refactor, which folks are free to ignore.

The problem is somewhat ameliorated by the fact that for most projects,
there will be a mapping between SHA-1 and SHA-256, so it'll be possible
to look up between the two, but it can still be confusing if the "wrong"
one appears in commit messages, say.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]

Re: [RFE] Teach hash-object to be able to choose signature types

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> trivial. I'm definitely not opposed if someone else is interested in
> picking it up or writing it; I don't believe my outstanding patches
> (which will likely show up on the list this weekend now that 2.23 is
> out) would affect it in any way.
>
> I'll try to push up the work that I'm doing into my "transition-interop"
> branch; it contains the work for literal hashing and a more significant
> refactor, which folks are free to ignore.

Thanks for pushing the SHA-256 transition forward.

>
> The problem is somewhat ameliorated by the fact that for most projects,
> there will be a mapping between SHA-1 and SHA-256, so it'll be possible
> to look up between the two, but it can still be confusing if the "wrong"
> one appears in commit messages, say.