{"thread":{"id":"51655","subject":"[RFE] Teach hash-object to be able to choose signature types","startedAt":"2019-08-16T22:22:30Z","lastAt":"2019-08-19T17:38:06Z","messageCount":3,"participants":["Randall S. Becker","brian m. carlson","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"380562","messageId":"009c01d55481$13d3ce20$3b7b6a60$@nexbridge.com","threadId":"51655","inReplyTo":null,"subject":"[RFE] Teach hash-object to be able to choose signature types","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2019-08-16T22:22:17Z","receivedAt":"2019-08-16T22:22:30Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"Hi All,\n\nI do not know whether this would be a good enhancement or micro project for\nsomeone (maybe me) to take on, but I'm wondering whether it might be a good\nidea to provide an option to hash-object to select the signature being\ncomputed. The use case begins when someone computes an object signature and\nstores a pre-converted SHA1 value. Then the repository is changed over to\nSHA256. When hash-object is next called, perhaps in a different clone or\nsome other \"next\" scenario, the new signature will be SHA256, if I\nunderstand this correctly, and from the perspective of the someone in the\nuse case, the signature mismatches.\n\nWhat I am proposing is an option like --signature-type=SHA1|SHA256 or\nsimilar as an option to hash-object to allow the non-default signature to be\nselected explicitly. This is not entirely trivial looking through the code\nand presumably would require either teaching hash_object_file_literally or\nhaving a separate method to do the alternate calculation.\n\nThoughts?\nRegards,\nRandall\n\n-- Brief whoami:\n NonStop developer since approximately 211288444200000000\n UNIX developer since approximately 421664400\n-- In my real life, I talk too much.\n\n\n\n"},{"id":"380574","messageId":"20190817015123.GD365197@genre.crustytoothpaste.net","threadId":"51655","inReplyTo":"009c01d55481$13d3ce20$3b7b6a60$@nexbridge.com","subject":"Re: [RFE] Teach hash-object to be able to choose signature types","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2019-08-17T01:51:41Z","receivedAt":"2019-08-17T01:52:04Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2019-08-16 at 22:22:17, Randall S. Becker wrote:\n> Hi All,\n> \n> I do not know whether this would be a good enhancement or micro project for\n> someone (maybe me) to take on, but I'm wondering whether it might be a good\n> idea to provide an option to hash-object to select the signature being\n> computed. The use case begins when someone computes an object signature and\n> stores a pre-converted SHA1 value. Then the repository is changed over to\n> SHA256. When hash-object is next called, perhaps in a different clone or\n> some other \"next\" scenario, the new signature will be SHA256, if I\n> understand this correctly, and from the perspective of the someone in the\n> use case, the signature mismatches.\n> \n> What I am proposing is an option like --signature-type=SHA1|SHA256 or\n> similar as an option to hash-object to allow the non-default signature to be\n> selected explicitly. This is not entirely trivial looking through the code\n> and presumably would require either teaching hash_object_file_literally or\n> having a separate method to do the alternate calculation.\n\nI'm actually working on this right now, and you're right, it isn't\ntrivial. I'm definitely not opposed if someone else is interested in\npicking it up or writing it; I don't believe my outstanding patches\n(which will likely show up on the list this weekend now that 2.23 is\nout) would affect it in any way.\n\nI'll try to push up the work that I'm doing into my \"transition-interop\"\nbranch; it contains the work for literal hashing and a more significant\nrefactor, which folks are free to ignore.\n\nThe problem is somewhat ameliorated by the fact that for most projects,\nthere will be a mapping between SHA-1 and SHA-256, so it'll be possible\nto look up between the two, but it can still be confusing if the \"wrong\"\none appears in commit messages, say.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"380720","messageId":"xmqqmug5xdhm.fsf@gitster-ct.c.googlers.com","threadId":"51655","inReplyTo":"20190817015123.GD365197@genre.crustytoothpaste.net","subject":"Re: [RFE] Teach hash-object to be able to choose signature types","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-08-19T17:37:57Z","receivedAt":"2019-08-19T17:38:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> trivial. I'm definitely not opposed if someone else is interested in\n> picking it up or writing it; I don't believe my outstanding patches\n> (which will likely show up on the list this weekend now that 2.23 is\n> out) would affect it in any way.\n>\n> I'll try to push up the work that I'm doing into my \"transition-interop\"\n> branch; it contains the work for literal hashing and a more significant\n> refactor, which folks are free to ignore.\n\nThanks for pushing the SHA-256 transition forward.\n\n>\n> The problem is somewhat ameliorated by the fact that for most projects,\n> there will be a mapping between SHA-1 and SHA-256, so it'll be possible\n> to look up between the two, but it can still be confusing if the \"wrong\"\n> one appears in commit messages, say.\n\n"}]}