On Tue, 19 Jul 2016, Duy Nguyen wrote:
On Tue, Jul 19, 2016 at 7:34 PM, David Lang <da...@lang.hm> wrote:
On Tue, 19 Jul 2016, Duy Nguyen wrote:
On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin
<johannes.schinde...@gmx.de> 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.
David Lang
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
