Junio C Hamano wrote: > In the proposed transition plan, the treatment of various signatures > (deliberately) makes the conversion not quite roundtrip. That's not precisely true. Details below. > When existing SHA-1 history in individual clones are converted to > NewHash, we obviously cannot re-sign the corresponding NewHash > contents with the same PGP key, so these converted objects will > carry only signature on SHA-1 contents. They can still be validated > when they are exported back to SHA-1 world via the fetch/push > protocol, and can be validated locally by converting them back to > SHA-1 contents and then passing the result to gpgv. Correct. > The plan also states, if I remember what I read correctly, that > newly created and signed objects (this includes signed commits and > signed tags; mergetags merely carry over what the tag object that > was merged was signed with, so we do not have to worry about them > unless the resulting commit that has mergetag is signed itself, but > that is already covered by how we handle signed commits) would be > signed both for NewHash contents and its corresponding SHA-1 > contents (after internally convering it to SHA-1 contents). Also correct. > would allow us to strip the signature over NewHash contents and > derive the SHA-1 contents to be shown to the outside world while > migration is going on and I'd imagine it would be a good practice; > it would allow us to sign something that allows everybody to verify, > when some participants of the project are not yet NewHash capable. The NewHash-based signature is included in the SHA-1 content as well, for the sake of round-tripping. It is not stripped out. > But the signing over SHA-1 contents has to stop at some point, when > everybody's Git becomes completely unaware of SHA-1. We may want to > have a guideline in the transition plan to (1) encourage signing for > both for quite some time, and (2) the criteria for us to decide when > to stop. Yes, spelling out a rough schedule is a good idea. I'll add that. A version of Git that is aware of NewHash should be able to verify NewHash signatures even for users that are using SHA-1 locally for the sake of faster fetches and pushes to SHA-1 based peers. In addition to a new enough Git, this requires the translation table to translate to NewHash to be present. So the criterion (2) is largely based on how up-to-date the Git used by users wanting to verify signatures is and whether they are willing to tolerate the performance implications of having a translation table. My hope is that when communicating with peers using the same hash function, the translation table will not add too much performance overhead. Thank you, Jonathan
