Re: Git and SHA-1 security (again)

On Tue, Jul 19, 2016 at 8:58 PM, Herczeg Zsolt [off-list ref] wrote:

2016-07-19 20:04 GMT+02:00 Duy Nguyen [off-list ref]:

quoted

On Tue, Jul 19, 2016 at 7:59 PM, David Lang [off-list ref] wrote:

quoted

On Tue, 19 Jul 2016, Duy Nguyen wrote:

quoted

On Tue, Jul 19, 2016 at 7:34 PM, David Lang [off-list ref] wrote:

quoted

On Tue, 19 Jul 2016, Duy Nguyen wrote:

quoted

On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin
[off-list ref] wrote:

quoted

quoted

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.

It could work, but does it worth it?

1) If you use multihash, you should assume that anything with SHA1
could be manipulated. That means you can "inject" something later to
that "old clone" anyway.

No it's not multihash. The repo only uses sha256, but by substituting
it with sha1 using the same dag, we can recreate the exact same sha1
repo (up to the conversion point). This is mostly to avoid people
injecting something because _you_ generate the repo locally.

2) Even if the content is re-hashed, it's hard to understand for a
user where the trust comes from. The user should decide weather he
trust (or not) the person who signed that octopus breakpoint.

Even without git you can achieve this security: Get the complete old
repository, make a signed tarball of it. If anytime later you want to
check that signatures, you can just use that tarball. I don't think
it's worth the trouble to create a native method for something which
is rare, and can be worked around easily. It's actually easier for a
user to understand the "trust relation" when using this workaround.

Referring to that signed-tarball approach, you may just as well drop
all signature data on conversion... As long as you can look up the
references to old hashes easily, I think it's usable enough.

It's more or less the signed-tarball approach in my view, except that
you recreate that tarball dynamically with your sha256 repo (so this
tarball is "signed" with sha256).
-- 
Duy