"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes:
> On 2024-03-14 at 12:47:16, Eric W. Biederman wrote:
>> That said I think a lot of think we do a lot of that today in practice
>> by simply detecting the length of the hash.
>
> That's only true for the dumb HTTP protocol. Everything else should not
> do that and we specifically want to avoid doing that, since we may very
> well end up with SHA-3-256 or another 256-bit hash instead of SHA-256 if
> there are sufficient cryptographic advances.
My apologies. I thought Jeff King was reporting that object-format
extension did not work, and that had been masked by a test.
I see you saying and a quick grep through the code supports that the
object-format extension is implemented, and that the primary problem
is that the Documentation varies slightly from what is implemented.
Looking at the code I am left with the question:
Is the object-format extension properly implemented in all cases?
If the object-format extension is properly implemented such that a
client and server mismatch can be detected I am for just Documenting
what is currently implemented and calling it good.
The reason for that is
Documentation/technical/hash-function-transition.txt does not expect
servers to support more than hash function. I don't have a perspective
that differs. So detecting what the client and server support and
failing if they differ should be good enough.
I am concerned that the current code may not report it's hash function
in all of the cases it needs to, to be able to detect a mismatch.
I look at commit 8b85ee4f47aa ("transport-helper: implement
object-format extensions") and I don't see anything that generates
":object-format=" after it has been asked for except the code
in remote-curl.c added in commit 7f60501775b2 ("remote-curl: implement
object-format extensions").
Maybe I am mistaken but a name like remote-curl has me strongly
suspecting that it does not cover all of the cases that git supports
that implement protocol v2.
I think I see some omissions in updating the protocol v2 Documentation.
Can some folks who understand how git protocol v2 is implemented better
that I do, tell me if I am seeing things or if it indeed looks like
there are some omissions in the object-format implementation?
Eric
