Re: RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

From: Blake Burkhart <bburky@bburky.com>
Date: Feb 13, 2016, 01:40 UTC
Message-ID: <CAP3OtXjyy+7cSi0S17FSsx8gnP1rKboeSAz_Hz1ZNVDuqcGASw@mail.gmail.com>
In-Reply-To: <20160210214945.GA5853@sigill.intra.peff.net>

On Wed, Feb 10, 2016 at 3:49 PM, Jeff King <peff@peff.net> wrote:

Show 7 quoted lines

>> 2. Servers that support resumable clone include a "resumable"
>> capability in the advertisement.
>
> Because the magic happens in the git protocol, that would mean this does
> not have to be limited to git-over-http. It could be "resumable=<url>"
> to point the client anywhere (the same server over a different protocol,
> another server, etc).

I'd like to call this out as a possible security issue before it gets implemented. Allowing the server to instruct the client what protocol to use is a security risk. This sounds like a fine feature, just do it carefully.

I reported a similar issue was discussed off list which eventually became CVE-2015-7545. Basically, git-submodule allowed a repository to specify any protocol via .gitmodules, causing the client to fetch an arbitrary URL using a protocol of the attacker's choice. Sadly, the existence of git-remote-ext allows easily executing arbitrary shell commands if the server can tell the client to use it. Furthermore, it's possible the client has some insecure or sensitive custom git remote helpers installed.

To address this GIT_ALLOW_PROTOCOL was introduced, and git-submodule now uses it as of 33cfccb. This environment variable specifies a default whitelist of protocols. Whoever implements this should probably make use of GIT_ALLOW_PROTOCOL to limit resumable clones to the same default whitelist that git-submodule now uses.

-- 
Blake Burkhart