Re: Bug? git submodule add SSL certificate problem: unable to get local issuer certificate

From: Jeff King <peff@peff.net>
Date: Mar 9, 2015, 07:43 UTC
Message-ID: <20150309074339.GA31866@peff.net>
In-Reply-To: <27F61CEE-F1D3-4B7F-B394-8D06A4AD8976@aschemann.net>

On Thu, Mar 05, 2015 at 04:20:10PM +0100, Aschemann Gerd wrote:

Show 12 quoted lines

> seems to be a bug: If adding a submodule from an https URL with a certificate issued by StartSSL (or even a private/self-signed one?) leads to the following error:
> 
>   $ git -c http.sslverify=false submodule add https://example.com/git/xxx.git
>   Cloning into 'xxx'...
>   fatal: unable to access 'https://example.com/git/xxx.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
>   Clone of 'https://example.com/git/xxx.git' into submodule path 'xxx' failed
> 
> Performing a simple clone works well:
> 
>   $ git -c http.sslverify=false clone https://example.com/git/xxx.git
>   Cloning into 'xxx'...
>   Password for 'https://example.com':

I think the problem is that the submodule code wipes all "local" environment variables before executing the submodule clone, and that includes the variable containing command-line config.

Config like this is in a funny boat. We do not want it to cross transport boundaries, so that if we run:

  git -c foo=bar clone /some/local/path

the process serving /some/local/path should not see the "foo" option[1]. But for submodules in the same repository, keeping the shared config is probably more reasonable (I can imagine a config variable that you might want to behave differently between the submodule and the main project, but I could not think of any off-hand, and I expect it would be a rare exception).

Submodule folks (cc'd) may have opinions.

-Peff

[1] This behavior comes from 655e8d9 (do not pass "git -c foo=bar"
    params to transport helpers, 2010-08-24), and the original
    discussion is here:

      http://thread.gmane.org/gmane.comp.version-control.git/154241/focus=154255

    I am tempted to simply drop the transport-layer blocking of config
    options. It is not buying us anything security-wise, and it could
    actually be convenient to pass options to the "other side". But it's
    probably a bad idea, if only because it would not be consistently
    applied to repos on the other side of git://, http://, or ssh
    sessions.

    So the sanest fix, if we want submodules to inherit the command-line
    config, would be to drop GIT_CONFIG_PARAMETERS from local_repo_env,
    and have the transport code suppress it manually.