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. -- Duy -- 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