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

From: Jens Lehmann <jens.lehmann@web.de>
Date: Mar 10, 2015, 08:56 UTC
Message-ID: <54FEB1CA.7020204@web.de>
In-Reply-To: <20150309074339.GA31866@peff.net>

Am 09.03.2015 um 20:43 schrieb Jeff King:

Show 32 quoted lines

> On Thu, Mar 05, 2015 at 04:20:10PM +0100, Aschemann Gerd wrote:
>
>> 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.

I tend to rather not share configs. While I agree that for the example which started this it would be correct to simply pass http.sslverify, that doesn't always make sense (e.g. it never does for a setting like core.worktree).

We already have two options for submodule add and update that are passed to the clone command (--reference & --depth), maybe it is time to add another one for passing config options to clone (which then get set permanently in the submodule's config).

Show 19 quoted lines

> -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.
>