Smart protocol fails to fetch with 'error parsing REF pkt-line'

[anatol]

Hello folks,

I am integrating my custom transport protocol and I am struck trying to understand the logic behind libgit2 smart protocol library implementation.

I am trying to implement a transport for our service. For simplicity the transport is a git protocol wrapped into HTTPS with extra authentication and validation. My implementation essentially sets up the connection and then simply reads/writes from the pipe and let libgit2 to deal with the git protocol parsing/handling.

Besides the complexity with authentication, there is nothing special about the service, it is a simple gerrit that serves traffic using git protocol. Here is an example of the initial communication sequence:

read: "000eversion 2\n000cls-refs\n0040fetch=filter ref-in-want sideband-all wait-for-done shallow\n0012server-option\n000fsession-id\n0010object-info\n0000"
write: "0014command=ls-refs\n00010009peel\n000csymrefs\n0000"
read: "105d75aad4252331fa6b532ea2265b9a599055cac432 HEAD symref-target:refs/heads/servicefoo/for-merged\n...."

Now I call git_remote_fetch()and my transport implementation connects the server. The *_read callback gets called, my implementation reads the first package (see it above) and passes it to libgit2. But libgit fails with error parsing REF pkt-line.

But I don't quite understand why. I started looking at the libgit2 code,

libgit2/src/libgit2/transports/smart.c

Line 130 in 585210a

static int git_smart__connect(

in particular. The error happens at the connect codepath:git_smart__connect() -> git_smart__store_refs() -> git_pkt_parse_line() -> ref_pkt() -> if (len < oid_hexsize. 000eversion 2 pktline is not handled by git_pkt_parse_line and passed down to ref_pkt. That function for some reason expects the line starts with SHA1 and then followed by capabilities. My server reply does not match this format. I even checked the protocol docs here https://git-scm.com/docs/protocol-v2 The doc says capabilities have its own pktline, and my server reply seems valid.

Could anyone explain what exactly git_smart__connect does here and why it does not handle a standard reply from the server?

[anatol]

Or does it mean that libgit2 did not implement git protocol v2 yet?

[ethomson]

That's right. I started doing some refactoring here but at the moment we don't support v2

[ethomson]

Note that clients request version 2 from the server, a server shouldn't default to v version 2.

From gitprotocol-v2.txt:

Initial Client Request
----------------------

In general a client can request to speak protocol v2 by sending
`version=2` through the respective side-channel for the transport being
used which inevitably sets `GIT_PROTOCOL`.  More information can be
found in linkgit:gitprotocol-pack[5] and linkgit:gitprotocol-http[5], as well as the
`GIT_PROTOCOL` definition in `git.txt`. In all cases the
response from the server is the capability advertisement.

[anatol]

Thank you for your reply!

I was able to modify my transport configuration and switch the server protocol from V2 to V0. And now my implementation works!

I started doing some refactoring here but at the moment we don't support v2

Do you have a link to your work and the issue that tracks it? I would love to test the V2 implementation when it gets closer to completion.