From: Felipe Contreras <felipe.contreras@gmail.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>,
Felipe Contreras <felipe.contreras@gmail.com>
Cc: Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Adam Majer <adamm@zombino.com>
Subject: Re: Is GIT_DEFAULT_HASH flawed?
Date: Sun, 07 May 2023 20:00:56 -0600 [thread overview]
Message-ID: <645857d8e8fd7_4e6129477@chronos.notmuch> (raw)
In-Reply-To: <ZFLmGYXgvyydLB5E@tapette.crustytoothpaste.net>
brian m. carlson wrote:
> On 2023-05-02 at 23:46:02, Felipe Contreras wrote:
> > In my view one repository should be able to have part SHA-1 history,
> > part SHA3-256 history, and part BLAKE2b history.
>
> That is practically very difficult and it means that it's hard to have
> confidence in the later history because SHA-1 is weak and you have to
> rely on it to verify the SHA-256 history later.
Why would I have to rely on SHA-1 to verify the SHA-256 history later
on?
> Since attacks always get better, SHA-1 will eventually be so weak that
> collisions can be computed in the amount of time we now take for MD4
> or MD5 collisions (i.e., seconds), and with your plan, we'd have to
> retain that history forever with the resulting lack of confidence in
> part of the history.
We have to do the same with your plan as well.
Your plan relies on SHA-256 being interchangeable with SHA-1, so if the
Git project decided to switch *today* to SHA-256, we would have two
object ids:
1. 69c786637d7a7fe3b2b8f7d989af095f5f49c3a8
2. 2b4ebdace10518280172449c012af17b51e9d46e023a91a5d3dd3a8ad9e4a116
This object would refer to a tree and a parent object with SHA-1 ids,
which would be OK, because they would be interchangeable with some
corresponding SHA-256 ids.
Isn't that your plan?
Therefore the SHA-1 of the parent of the commit, and the tree of the
commit would be trusted and retained forever.
> This also doesn't work with various structures like trees, the index,
> and pack and index formats, which have no indication of the algorithm
> used and simply rely on fixed-size, often 4-byte aligned object IDs
> without any metadata.
So? The index and pack objects can be regenerated, so at any point in
time they could be regenerated for SHA-1 or SHA-256.
The tree object is a no-brainer. For an object of type "commit:256" you
require a tree of type "tree:256". Easy.
> In addition, the internals of the code often don't pass around enough
> data to make these values variable and thus this approach would
> substantially complicate the code in many ways.
Really? `enum object_type` is not passed around?
> Also, we've already decided on the current design a long time ago with
> the transition plan after extensive, thoughtful discussion by many
> people.
Who is "we"?
I've participated in many discussions in the git mailing list where the
consensus is that 99% of people decide to do something, and that
something never happens.
The fact that "we" have decided something doesn't carry as much weight
as you seem to think it does.
Moreover, haven't "we" decided that this transitioning plan is
*tentantive*, and the SHA-256 feature is *experimental*?
> Very few people other than me have worked on sending patches to
> work on the hash function transition, and that work up to now has all
> been done on my personal time, without compensation of any sort, out of
> a desire to improve the project.
Which seems to suggest if there is a need, it's not very pressing.
Doesn't it?
> Lots of people have opined on how it should have been different
> without sending any patches.
As is typical.
> If you would like to propose patches for the extensive amount of work
> to implement your solution, then we could consider them, although I
> will warn you that your approach will likely require at least several
> hundred patches.
That's not an issue. I've started projects with several hundred patches
just to prove that something is possible.
> However, I refer you to the list archives to determine why
> your approach is not the one we chose and is not, in my view, the best
> path forward.
Yeah? Provide me with *one* mail proposing my approach.
> I should also be clear that I have no intention of submitting patches
> to change our approach now or in the future, or redoing the patches
> I've already sent.
You don't have to. (and it's not really necessary as it's typically the
case that people don't provide patches for designs that compete against
their own).
> > The fact that apparently it's so easy to clone a repository with
> > the wrong hash algorithm should give developers pause, as it means the
> > whole point of using cryptographic hash algorithms to ensure the
> > integrity of the commit history is completely gone.
>
> No, it doesn't. It means that our empty repositories until recently
> lacked any indication of the algorithm or other capabilities, which was
> a mistake in our original protocol design that has now been corrected.
Yes it does.
Can I clone a repository that already transitioned to SHA-256, and then
push a SHA-1 commit?
Well, of course I can't because that's not currently implemented, but if
we followed the current plan that apparently "we" have decided on, it
should be.
> If you interact with the repository later on when it has data, then if
> you're using the wrong hash algorithm, you'll find that you get a
> helpful error message that that's not yet supported.
That isn't true according to your plan.
SHA-1 would be interchangeable with SHA-256, would it not? So according
to the current plan, I would be able to push a SHA-1 commit on a SHA-256
repository.
---
Is it not the case that the current plan aims to have support for SHA-1
and SHA-256 object ids at the same time?
In other words: in your ideal world, the following object ids would
*both* refer to the same git object:
1. 69c786637d7a7fe3b2b8f7d989af095f5f49c3a8
2. 2b4ebdace10518280172449c012af17b51e9d46e023a91a5d3dd3a8ad9e4a116
Would they not?
--
Felipe Contreras
next prev parent reply other threads:[~2023-05-08 2:01 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-05 10:28 git clone of empty repositories doesn't preserve hash Adam Majer
2023-04-05 19:04 ` Junio C Hamano
2023-04-05 19:47 ` Adam Majer
2023-04-05 20:01 ` Jeff King
2023-04-05 20:40 ` Junio C Hamano
2023-04-05 21:15 ` Junio C Hamano
2023-04-05 21:26 ` Jeff King
2023-04-05 22:48 ` brian m. carlson
2023-04-06 13:11 ` Adam Majer
2023-04-25 21:35 ` brian m. carlson
2023-04-25 22:24 ` Junio C Hamano
2023-04-25 23:12 ` Junio C Hamano
2023-04-26 0:20 ` brian m. carlson
2023-04-26 11:25 ` Jeff King
2023-04-26 15:08 ` Junio C Hamano
2023-04-26 15:13 ` [PATCH] doc: GIT_DEFAULT_HASH is and will be ignored during "clone" Junio C Hamano
2023-04-26 21:06 ` brian m. carlson
2023-04-27 4:46 ` git clone of empty repositories doesn't preserve hash Jeff King
2023-04-26 10:51 ` Jeff King
2023-04-26 15:42 ` Junio C Hamano
2023-04-26 20:40 ` brian m. carlson
2023-04-26 20:53 ` [PATCH 0/2] Fix empty SHA-256 clones with v0 and v1 brian m. carlson
2023-04-26 20:53 ` [PATCH 1/2] http: advertise capabilities when cloning empty repos brian m. carlson
2023-04-26 21:14 ` Junio C Hamano
2023-04-26 21:28 ` brian m. carlson
2023-04-27 5:00 ` Jeff King
2023-04-27 5:30 ` Jeff King
2023-04-27 20:40 ` Junio C Hamano
2023-04-26 20:53 ` [PATCH 2/2] Honor GIT_DEFAULT_HASH for empty clones without remote algo brian m. carlson
2023-04-26 21:18 ` Junio C Hamano
2023-04-26 21:33 ` Junio C Hamano
2023-04-27 5:43 ` Jeff King
2023-05-02 23:46 ` Is GIT_DEFAULT_HASH flawed? Felipe Contreras
2023-05-03 9:03 ` Adam Majer
2023-05-03 15:44 ` Felipe Contreras
2023-05-03 17:21 ` Adam Majer
2023-05-08 0:34 ` Felipe Contreras
2023-05-03 9:09 ` demerphq
2023-05-03 18:20 ` Felipe Contreras
2023-05-03 22:54 ` brian m. carlson
2023-05-08 2:00 ` Felipe Contreras [this message]
2023-05-08 21:38 ` brian m. carlson
2023-05-09 10:32 ` Oswald Buddenhagen
2023-05-09 16:47 ` Junio C Hamano
2023-04-26 21:12 ` [PATCH 0/2] Fix empty SHA-256 clones with v0 and v1 Junio C Hamano
2023-04-27 4:56 ` git clone of empty repositories doesn't preserve hash Jeff King
2023-05-01 17:00 ` [PATCH v2 0/1] Fix empty SHA-256 clones with v0 and v1 brian m. carlson
2023-05-01 17:00 ` [PATCH v2 1/1] upload-pack: advertise capabilities when cloning empty repos brian m. carlson
2023-05-01 22:40 ` Jeff King
2023-05-01 22:51 ` Junio C Hamano
2023-05-01 17:37 ` [PATCH v2 0/1] Fix empty SHA-256 clones with v0 and v1 Junio C Hamano
2023-05-17 19:24 ` [PATCH v3 " brian m. carlson
2023-05-17 19:24 ` [PATCH v3 1/1] upload-pack: advertise capabilities when cloning empty repos brian m. carlson
2023-05-17 21:48 ` [PATCH v3 0/1] Fix empty SHA-256 clones with v0 and v1 Junio C Hamano
2023-05-17 22:28 ` brian m. carlson
2023-05-18 18:28 ` Jeff King
2023-05-19 15:32 ` brian m. carlson
2023-04-05 21:23 ` git clone of empty repositories doesn't preserve hash Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=645857d8e8fd7_4e6129477@chronos.notmuch \
--to=felipe.contreras@gmail.com \
--cc=adamm@zombino.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).