Hi Duy, On Tue, 19 Jul 2016, Duy Nguyen wrote: > On Tue, Jul 19, 2016 at 7:59 PM, David Lang <david@xxxxxxx> wrote: > > On Tue, 19 Jul 2016, Duy Nguyen wrote: > > > >> On Tue, Jul 19, 2016 at 7:34 PM, David Lang <david@xxxxxxx> wrote: > >>> > >>> On Tue, 19 Jul 2016, Duy Nguyen wrote: > >>> > >>>> On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin > >>>> <Johannes.Schindelin@xxxxxx> wrote: > >>>>>> > >>>>>> > >>>>>> But we can recreate SHA-1 from the same content and verify GPG, > >>>>>> right? I know it's super expensive, but it feels safer to not > >>>>>> carry SHA-1 around when it's not secure anymore (I recall > >>>>>> something about exploiting the weakest link when you have both > >>>>>> sha1 and sha256 in the object content). Rehashing would be done > >>>>>> locally and is better controlled. > >>>>> > >>>>> You could. But how would you determine whether to recreate the > >>>>> commit object from a SHA-1-ified version of the commit buffer? > >>>>> Fall back if the original did not match the signature? > >>>> > >>>> Any repo would have a cut point when they move to sha256 (or > >>>> whatever new hash), if we can record this somewhere (e.g. as a tag > >>>> or a bunch of tags, or some dummy commits to mark the heads of the > >>>> repo) then we only verify gpg signatures _in_ the repository before > >>>> this point. > >>> > >>> remember that a repo doesn't have a single 'now', each branch has > >>> it's own head, and you can easily go back to prior points and branch > >>> off from there. > >>> > >>> Since timestamps in repos can't be trusted (different people's > >>> clocks may not be in sync), how would you define this cutoff point? > >> > >> The set of all heads at the time the conversion happens (maybe plus > >> all the real tags). We can make an octopus merge commit to cover all > >> the heads, then it can be the reference point. > > > > so to make sure I'm understanding this, anything not reachable from > > that merge must be the new hash, correct? Including forks, merges, etc > > that happen from earlier points in the history. > > Yes everything except that merge and everything reachable from it, the > whole old clone, basically. But that strategy *still* ignores the distributed nature of Git. Just because *you* make that merge at a certain point does not necessarily mean that I make it at that point, too. Any approach that tries to have one single point of conversion will most likely fall short of a solution. To be honest, I am less concerned about the GPG-signed commits (after all, after switching to a more secure hash algorithm, a maintainer could cross-sign all signed commits, or only the branch tips or tags, as new tags, to reinstitute trust). I am much more concerned about references to commits, both inside and outside the repository. That is, if I read anywhere on the internet about Git having added support for `git add --chmod=+x <file>` in 4e55ed3 (add: add --chmod=+x / --chmod=-x options, 2016-05-31), I want to find that commit by that reference. And I am of course concerned what should happen if a user wants to fetch from, or push to, a SHA-1-hashed remote repository into, or from, a SHA-256-hashed local one. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html