* Bug? git submodule add SSL certificate problem: unable to get local issuer certificate
[not found] <F24DBF8D-40EE-4C8D-AE9C-463E59C4AAD7@aschemann.net>
@ 2015-03-05 15:20 ` Aschemann Gerd
2015-03-09 7:43 ` Jeff King
0 siblings, 1 reply; 4+ messages in thread
From: Aschemann Gerd @ 2015-03-05 15:20 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 857 bytes --]
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
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 204 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bug? git submodule add SSL certificate problem: unable to get local issuer certificate
2015-03-05 15:20 ` Bug? git submodule add SSL certificate problem: unable to get local issuer certificate Aschemann Gerd
@ 2015-03-09 7:43 ` Jeff King
2015-03-10 8:56 ` Jens Lehmann
0 siblings, 1 reply; 4+ messages in thread
From: Jeff King @ 2015-03-09 7:43 UTC (permalink / raw)
To: Aschemann Gerd; +Cc: Jonathan Nieder, Jens Lehmann, Heiko Voigt, git
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bug? git submodule add SSL certificate problem: unable to get local issuer certificate
2015-03-09 7:43 ` Jeff King
@ 2015-03-10 8:56 ` Jens Lehmann
2015-03-21 13:22 ` Jeff King
0 siblings, 1 reply; 4+ messages in thread
From: Jens Lehmann @ 2015-03-10 8:56 UTC (permalink / raw)
To: Jeff King, Aschemann Gerd; +Cc: Jonathan Nieder, Heiko Voigt, git
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.
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bug? git submodule add SSL certificate problem: unable to get local issuer certificate
2015-03-10 8:56 ` Jens Lehmann
@ 2015-03-21 13:22 ` Jeff King
0 siblings, 0 replies; 4+ messages in thread
From: Jeff King @ 2015-03-21 13:22 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Aschemann Gerd, Jonathan Nieder, Heiko Voigt, git
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-03-21 13:23 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <F24DBF8D-40EE-4C8D-AE9C-463E59C4AAD7@aschemann.net>
2015-03-05 15:20 ` Bug? git submodule add SSL certificate problem: unable to get local issuer certificate Aschemann Gerd
2015-03-09 7:43 ` Jeff King
2015-03-10 8:56 ` Jens Lehmann
2015-03-21 13:22 ` Jeff King
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).