# Bug? git submodule add SSL certificate problem: unable to get local issuer certificate 4 messages from 2015-03-05 to 2015-03-21. Participants: Aschemann Gerd, Jeff King, Jens Lehmann. Thread: https://gitlist.dev/t/38709 ## Aschemann Gerd, 2015-03-05 15:20 Subject: Bug? git submodule add SSL certificate problem: unable to get local issuer certificate Message-ID: <27F61CEE-F1D3-4B7F-B394-8D06A4AD8976@aschemann.net> URL: https://gitlist.dev/e/27F61CEE-F1D3-4B7F-B394-8D06A4AD8976%40aschemann.net In-Reply-To: ``` Hi, 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': Cheers, Gerd -- Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) +49/173/3264070 -- gerd@aschemann.net -- http://www.aschemann.net ``` ## Jeff King, 2015-03-09 07:43 Subject: Re: Bug? git submodule add SSL certificate problem: unable to get local issuer certificate Message-ID: <20150309074339.GA31866@peff.net> URL: https://gitlist.dev/e/20150309074339.GA31866%40peff.net In-Reply-To: <27F61CEE-F1D3-4B7F-B394-8D06A4AD8976@aschemann.net> ``` 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. -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. ``` ## Jens Lehmann, 2015-03-10 08:56 Subject: Re: Bug? git submodule add SSL certificate problem: unable to get local issuer certificate Message-ID: <54FEB1CA.7020204@web.de> URL: https://gitlist.dev/e/54FEB1CA.7020204%40web.de In-Reply-To: <20150309074339.GA31866@peff.net> ``` Am 09.03.2015 um 20:43 schrieb Jeff King: > 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). > -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. > ``` ## Jeff King, 2015-03-21 13:22 Subject: Re: Bug? git submodule add SSL certificate problem: unable to get local issuer certificate Message-ID: <20150321132259.GA11843@peff.net> URL: https://gitlist.dev/e/20150321132259.GA11843%40peff.net In-Reply-To: <54FEB1CA.7020204@web.de> ``` On Tue, Mar 10, 2015 at 09:56:42PM +1300, Jens Lehmann wrote: > >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). Sorry, I missed this earlier, as it fell into a spam trap. What you're proposing does make sense to me. We already have "git clone -c", so I think it would just be a matter of passing along that option in the submodule code. -Peff ```