Bug: invalid headers for git over http

Valentin valentin at vrvis.at
Wed Oct 28 14:46:10 UTC 2020


Hi,

Thanks for your quick response.

> That bug is something I missed when porting to py3. Apparently, other 
> Git implementations are less strict, and it didn't come up while testing.

Yes, i noticed that too. had to try hard to reproduce this.

> But I think the fix can be made simpler and more complete:
> https://kallithea-scm.org/repos/kallithea-incoming/changeset/b9be708625087a6618240d614d27782632a80b2b 
> 
> 
> Can you confirm this works as well for you?

Yes it does work and i agree it is a better solution.

Cheers,
Valentin


> On 10/28/20 2:13 PM, Valentin wrote:
>> Hi,
>>
>> I've noticed cases in which kallithea returns headers that seem 
>> incorrect on git requests over http.
>> This first occurred as some users had problems fetching repos from our 
>> kallithea instance with software that uses the JGit library on Windows 
>> (user agent string: JGit/5.4.2.201908231537-r).
>> The error message noted:
>> 'git fetch' command failed (repository dir: <TeamCity data 
>> dir>/system/caches/git/git-233054F9.git).
>> stderr: https:<redacted>: expected Content-Type 
>> application/x-git-upload-pack-result; received Content-Type 
>> application/x-b'git-upload-pack'-result
>>
>> I was able to reproduce this header by using git for windows, although 
>> it didn't produce an error:
>> valentin at CASHEW MINGW64 ~
>> $ GIT_CURL_VERBOSE=1 git clone https:<redacted>
>> Cloning into 'master'...
>>
>> ...
>> ...
>> 12:14:51.522612 http.c:721              <= Recv header, 0000000059 
>> bytes (0x0000003b)
>> 12:14:51.522612 http.c:733              <= Recv header: Content-Type: 
>> application/x-git-upload-pack-advertisement
>> ...
>> ...
>> 12:15:32.147657 http.c:721              <= Recv header, 0000000055 
>> bytes (0x00000037)
>> 12:15:32.147657 http.c:733              <= Recv header: Content-Type: 
>> application/x-b'git-upload-pack'-result
>>
>>
>> The problem arises in pygrack.py [0] where encode('utf-8') is used on 
>> line 178:
>> resp.content_type = 'application/x-%s-result' % 
>> git_command.encode('utf-8')
>>
>> in contrary, on line 128 str() is used:
>> resp.content_type = 'application/x-%s-advertisement' % str(git_command)
>>
>> I patched my kallithea instance to use str() (see the attached diff) 
>> which resolves the problem.
>> I think this is safe to do, as git_command is checked against valid 
>> commands before and therefor must be convertible to a string.
>>
>> Hope i got that right and you can integrate this into an upcoming 
>> release.
>>
>> Cheers,
>> Valentin
>>
>>
>> [0] 
>> https://kallithea-scm.org/repos/kallithea/files/855b37d3bacdc6175566ca7d23c19e2352da1087/kallithea/lib/middleware/pygrack.py 
>>
>>
>>
>> _______________________________________________
>> kallithea-general mailing list
>> kallithea-general at sfconservancy.org
>> https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
> 
> 
> 


More information about the kallithea-general mailing list