From: Johannes Schindelin <hidden> Date: 2016-07-18 07:12:55
Hi Zsolt,
On Mon, 18 Jul 2016, Herczeg Zsolt wrote:
I think converting is a much better option. Use a single-hash storage, and
convert everything to that on import/clone/pull.
That ignores two very important issues that I already had mentioned:
- existing references, both in-repository, e.g. in commit messages
referring to earlier commits, as well as out-of-repository, e.g.
referring to commits in mails, blog posts, etc
- GPG-signed commits
Those issues cannot just be hand-waved away.
The "convert everything" strategy also ignores the problem of interacting
with servers and collaborators. Think of hosting repositories,
rediscovering forgotten work trees, and of the "D" in DSCM.
Ciao,
Johannes
I think converting is a much better option. Use a single-hash storage, and
convert everything to that on import/clone/pull.
That ignores two very important issues that I already had mentioned:
That's not true. If you double-check the next part of my message, you
I just showed that an automatic two-way mapping could solve these
problems! (I even give briefs explanation how to handle referencing
and signature verification in those cases.)
My point is not to throw out old hashes and break signatures. My point
is to convert the data storage, and use mapping to resolve problems
with those old hashes and signatures. A single-hash data storage is
obviously way easier to handle, than a multi-hash mass. (See Linus's
old e-mail: multiple hashes [=meaning database keys] for the same
content is a complete nonsense in git-speak)
The "convert everything" strategy also ignores the problem of interacting
with servers and collaborators. Think of hosting repositories,
rediscovering forgotten work trees, and of the "D" in DSCM.
That's not an issue when we're working with a single repository. It's
reasonable to ask for all git clients of the same repository, to
support the same hash. Yes, you have the need to configure the hash
algo on a per-repository basis but that's all. For importing and
co-working between different repositories, it's a bit harder, problem,
but it's possible to handle the conversions correctly.
From: Johannes Schindelin <hidden> Date: 2016-07-18 15:58:10
Hi Zsolt,
On Mon, 18 Jul 2016, Herczeg Zsolt wrote:
quoted
quoted
I think converting is a much better option. Use a single-hash
storage, and convert everything to that on import/clone/pull.
That ignores two very important issues that I already had mentioned:
That's not true. If you double-check the next part of my message, you I
just showed that an automatic two-way mapping could solve these
problems! (I even give briefs explanation how to handle referencing and
signature verification in those cases.)
My point is not to throw out old hashes and break signatures. My point
is to convert the data storage, and use mapping to resolve problems
with those old hashes and signatures.
If you convert the data storage, then the SHA-1s listed in the commit
objects will have to be rewritten, and then the GPG signature will not
match anymore.
Call e.g. `git cat-file commit 44cc742a8ca17b9c279be4cc195a93a6ef7a320e`
to see the anatomy of a gpg-signed commit object.
Ciao,
Johannes
On Mon, Jul 18, 2016 at 5:57 PM, Johannes Schindelin
[off-list ref] wrote:
Hi Zsolt,
On Mon, 18 Jul 2016, Herczeg Zsolt wrote:
quoted
quoted
quoted
I think converting is a much better option. Use a single-hash
storage, and convert everything to that on import/clone/pull.
That ignores two very important issues that I already had mentioned:
That's not true. If you double-check the next part of my message, you I
just showed that an automatic two-way mapping could solve these
problems! (I even give briefs explanation how to handle referencing and
signature verification in those cases.)
My point is not to throw out old hashes and break signatures. My point
is to convert the data storage, and use mapping to resolve problems
with those old hashes and signatures.
If you convert the data storage, then the SHA-1s listed in the commit
objects will have to be rewritten, and then the GPG signature will not
match anymore.
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.
--
Duy
My point is not to throw out old hashes and break signatures. My point
is to convert the data storage, and use mapping to resolve problems
with those old hashes and signatures.
If you convert the data storage, then the SHA-1s listed in the commit
objects will have to be rewritten, and then the GPG signature will not
match anymore.
Call e.g. `git cat-file commit 44cc742a8ca17b9c279be4cc195a93a6ef7a320e`
to see the anatomy of a gpg-signed commit object.
Yes and no. That's the reason you need the two-way lookup table. If
you need to verify a commit which was signed as SHA-1, you must use
the lookup table in reverse. This way you can reconstruct the original
commit structure, which than can be verified. Of course it's work to
do so but you only need to develop the new signature verification
algorithm. You save much more on the other side where you don't have
to rework all the other algorithms to multi-hash.
Another interesting point is that multi-hash storage, actively hurts
signature security! (Duy just mentoined that while I'm writing.) A
signed commit (or tag) is just as secure as the least secure hash it
refers (directly or indirectly). Let's imagine that you make a new a
commit, and there is on old file in the tree somewhere. That's a weak
point: cause it has SHA-1 hash, someone can replace it (and thus
change your commits content.
I would clearly mark any signature wether it's SHA-1 or SHA2 (or
anything else) based, and strictly allow that hash in all the trees
and objects while verifying that commit. If it's not the same
hash-type as the storage-key, than use the lookup table for conversion
before check. (This has some interesting side-effects, but it's all
about good implementation).
From: Johannes Schindelin <hidden> Date: 2016-07-19 07:19:32
Hi Duy,
On Mon, 18 Jul 2016, Duy Nguyen wrote:
On Mon, Jul 18, 2016 at 5:57 PM, Johannes Schindelin
[off-list ref] wrote:
quoted
On Mon, 18 Jul 2016, Herczeg Zsolt wrote:
quoted
quoted
quoted
I think converting is a much better option. Use a single-hash
storage, and convert everything to that on import/clone/pull.
That ignores two very important issues that I already had mentioned:
That's not true. If you double-check the next part of my message, you I
just showed that an automatic two-way mapping could solve these
problems! (I even give briefs explanation how to handle referencing and
signature verification in those cases.)
My point is not to throw out old hashes and break signatures. My point
is to convert the data storage, and use mapping to resolve problems
with those old hashes and signatures.
If you convert the data storage, then the SHA-1s listed in the commit
objects will have to be rewritten, and then the GPG signature will not
match anymore.
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? That would pose at least these two
problems:
1. The point of a signature is trust. If all of a sudden the signature
does not match what is supposedly signed, that trust is broken.
2. The point of going to a stronger hash is to increase the trust. If
any developer could decide to sign the SHA-1-ified version of any future
commit, and Git validating it, it would be even worse than not switching
to a new hash: it would leave us open to collision attacks *and* pretend
that we prevented such attacks.
The more I think about it, the more I am convinced that we have no choice
but allow mixed hashes (i.e. both 160-bit SHA-1 and 256-bit new hash,
whatever we settle on). Otherwise there would be no reliable and
trustworthy upgrade path.
But maybe there is a clever strategy I failed to think of?
Ciao,
Dscho
From: Johannes Schindelin <hidden> Date: 2016-07-19 07:22:21
Hi Zsolt,
On Mon, 18 Jul 2016, Herczeg Zsolt wrote:
quoted
quoted
My point is not to throw out old hashes and break signatures. My point
is to convert the data storage, and use mapping to resolve problems
with those old hashes and signatures.
If you convert the data storage, then the SHA-1s listed in the commit
objects will have to be rewritten, and then the GPG signature will not
match anymore.
Call e.g. `git cat-file commit 44cc742a8ca17b9c279be4cc195a93a6ef7a320e`
to see the anatomy of a gpg-signed commit object.
Yes and no. That's the reason you need the two-way lookup table. If
you need to verify a commit which was signed as SHA-1, you must use
the lookup table in reverse.
That pretends that it is both easy and trustworthy to know when (and how)
to recreate the SHA-1-ified version of the commit object.
Neither is the case, though.
Ciao,
Johannes
On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin
[off-list ref] wrote:
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.
That would pose at least these two problems:
1. The point of a signature is trust. If all of a sudden the signature
does not match what is supposedly signed, that trust is broken.
2. The point of going to a stronger hash is to increase the trust. If
any developer could decide to sign the SHA-1-ified version of any future
commit, and Git validating it, it would be even worse than not switching
to a new hash: it would leave us open to collision attacks *and* pretend
that we prevented such attacks.
GPG signatures are still valid on the old repo (we will keep old repos
around forever, I suppose). And because they sign on the "weak" hash,
sha1, at some point they will be broken (but until then we can still
regenerate sha1 and verify locally). When sha1 is broken, GPG
signatures of the past can't be trusted anymore.
If people care enough about the past, they should re-sign (at least
for tags). Commits can be re-signed by the person who does the
conversion. Yes you have to trust that person. Sort of a painful fresh
start, with hopefully better security.
--
Duy
From: David Lang <hidden> Date: 2016-07-19 17:34:52
On Tue, 19 Jul 2016, Duy Nguyen wrote:
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?
David Lang
On Tue, Jul 19, 2016 at 7:34 PM, David Lang [off-list ref] wrote:
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.
--
Duy
From: David Lang <hidden> Date: 2016-07-19 17:59:37
On Tue, 19 Jul 2016, Duy Nguyen wrote:
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.
David Lang
On Tue, Jul 19, 2016 at 7:59 PM, David Lang [off-list ref] wrote:
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.
--
Duy
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.
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.
From: Johannes Schindelin <hidden> Date: 2016-07-20 12:29:15
Hi Duy,
On Tue, 19 Jul 2016, Duy Nguyen wrote:
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.
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
On Wed, Jul 20, 2016 at 2:28 PM, Johannes Schindelin
[off-list ref] wrote:
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.
OK I see the difference in our views now. To me an sha256 repo would
see an sha1 repo as a _foreign_ DVCS, pretty much like git sees
mercurial now. So a transition from sha1 to sha256 is not that
different from cvs -> svn -> a dvcs bubble -> git.
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.
to follow the above, in my view, interaction with sha1 repos go
through some conversion bridges like what we have with hg and svn. I
don't know if we are going this route. It's certainly simpler and
people already have experiences (from previous migration) to prepare
for it.
--
Duy
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
From: Stefan Beller <hidden> Date: 2016-07-20 17:10:11
On Wed, Jul 20, 2016 at 7:44 AM, Duy Nguyen [off-list ref] wrote:
On Wed, Jul 20, 2016 at 2:28 PM, Johannes Schindelin
[off-list ref] wrote:
quoted
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.
OK I see the difference in our views now. To me an sha256 repo would
see an sha1 repo as a _foreign_ DVCS, pretty much like git sees
mercurial now. So a transition from sha1 to sha256 is not that
different from cvs -> svn -> a dvcs bubble -> git.
quoted
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.
to follow the above, in my view, interaction with sha1 repos go
through some conversion bridges like what we have with hg and svn. I
don't know if we are going this route. It's certainly simpler and
people already have experiences (from previous migration) to prepare
for it.
When treating the SHA1 version as a foreign dvcs and the SHA256
as the real deal, we could introduce "pointer objects", and during the
conversion
create a 4e55ed3 pointer that points to the SHA256 commit of (add:
add --chmod=+x / --chmod=-x options, 2016-05-31). Ideally we would
not even expose this sort of object a lot, e.g. git show <pointer> would just
redirect automatically. Instead of a new class of "pointer objects" we could
also solve this via a lot of refs. (refs/old-sha1/4e55ed3 pointing to
the converted
commit; Though we would need to accept partial refs names then :/)
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Philip Oakley <hidden> Date: 2016-08-22 22:01:23
Sorry if I'm dropping in at the wrong point (this is one I'd bookmarked)..
From: "Duy Nguyen" <redacted>
Sent: Wednesday, July 20, 2016 3:44 PM
On Wed, Jul 20, 2016 at 2:28 PM, Johannes Schindelin
[off-list ref] wrote:
quoted
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.
OK I see the difference in our views now. To me an sha256 repo would
see an sha1 repo as a _foreign_ DVCS, pretty much like git sees
mercurial now. So a transition from sha1 to sha256 is not that
different from cvs -> svn -> a dvcs bubble -> git.
I think that within Git, that it is possible to have inter-workability (for
those parts that negotiate) between instances with different views about the
availability of two hash types. Fetch/push negotiation is a normal part of
working with a remote.
quoted
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.
to follow the above, in my view, interaction with sha1 repos go
through some conversion bridges like what we have with hg and svn. I
don't know if we are going this route. It's certainly simpler and
people already have experiences (from previous migration) to prepare
for it.
--
The main thought was that rather than worrying about which advanced hash to
pick (with all the arguments that entails), rather it is worth reducing the
problem space to create a 'toy problem', to look at the interaction issues.
For the toy problem view we'd keep the current oid length (so that the
transmission formats don't change size), however we swap the old-new to make
sha1 the new hash and use an older shorter hash (e.g. md5) to investigate
the transition from a short to long hash.
Keeping it as a 'toy problem' avoids folks having too much invested in the
new hash choice, rather the interworking can be more easily sorted, and some
issue can be punted on (e.g. the choice of salt to extend the md5 to the
sha1, and collisions therein).
--
Philip