"brian m. carlson" [off-list ref] writes:

On 2024-03-14 at 12:47:16, Eric W. Biederman wrote:

quoted

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