{"thread":{"id":"38709","subject":"Bug? git submodule add SSL certificate problem: unable to get local issuer certificate","startedAt":"2015-03-05T15:20:10Z","lastAt":"2015-03-21T13:22:59Z","messageCount":4,"participants":["Aschemann Gerd","Jeff King","Jens Lehmann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"257079","messageId":"27F61CEE-F1D3-4B7F-B394-8D06A4AD8976@aschemann.net","threadId":"38709","inReplyTo":"F24DBF8D-40EE-4C8D-AE9C-463E59C4AAD7@aschemann.net","subject":"Bug? git submodule add SSL certificate problem: unable to get local issuer certificate","fromName":"Aschemann Gerd","fromEmail":"gerd@aschemann.net","sentAt":"2015-03-05T15:20:10Z","receivedAt":"2015-03-05T15:20:10Z","isPatch":false,"sender":{"key":"gerd@aschemann.net","avatar":null},"body":"Hi,\n\nseems 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:\n\n  $ git -c http.sslverify=false submodule add https://example.com/git/xxx.git\n  Cloning into 'xxx'...\n  fatal: unable to access 'https://example.com/git/xxx.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none\n  Clone of 'https://example.com/git/xxx.git' into submodule path 'xxx' failed\n\nPerforming a simple clone works well:\n\n  $ git -c http.sslverify=false clone https://example.com/git/xxx.git\n  Cloning into 'xxx'...\n  Password for 'https://example.com':\n\nCheers,\n  Gerd\n\n--\nGerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas)\n+49/173/3264070 -- gerd@aschemann.net -- http://www.aschemann.net\n\n"},{"id":"257367","messageId":"20150309074339.GA31866@peff.net","threadId":"38709","inReplyTo":"27F61CEE-F1D3-4B7F-B394-8D06A4AD8976@aschemann.net","subject":"Re: Bug? git submodule add SSL certificate problem: unable to get local issuer certificate","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-03-09T07:43:39Z","receivedAt":"2015-03-09T07:43:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 05, 2015 at 04:20:10PM +0100, Aschemann Gerd wrote:\n\n> 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:\n> \n>   $ git -c http.sslverify=false submodule add https://example.com/git/xxx.git\n>   Cloning into 'xxx'...\n>   fatal: unable to access 'https://example.com/git/xxx.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none\n>   Clone of 'https://example.com/git/xxx.git' into submodule path 'xxx' failed\n> \n> Performing a simple clone works well:\n> \n>   $ git -c http.sslverify=false clone https://example.com/git/xxx.git\n>   Cloning into 'xxx'...\n>   Password for 'https://example.com':\n\nI think the problem is that the submodule code wipes all \"local\"\nenvironment variables before executing the submodule clone, and that\nincludes the variable containing command-line config.\n\nConfig like this is in a funny boat. We do not want it to cross\ntransport boundaries, so that if we run:\n\n  git -c foo=bar clone /some/local/path\n\nthe process serving /some/local/path should not see the \"foo\" option[1].\nBut for submodules in the same repository, keeping the shared config is\nprobably more reasonable (I can imagine a config variable that you might\nwant to behave differently between the submodule and the main project,\nbut I could not think of any off-hand, and I expect it would be a rare\nexception).\n\nSubmodule folks (cc'd) may have opinions.\n\n-Peff\n\n[1] This behavior comes from 655e8d9 (do not pass \"git -c foo=bar\"\n    params to transport helpers, 2010-08-24), and the original\n    discussion is here:\n\n      http://thread.gmane.org/gmane.comp.version-control.git/154241/focus=154255\n\n    I am tempted to simply drop the transport-layer blocking of config\n    options. It is not buying us anything security-wise, and it could\n    actually be convenient to pass options to the \"other side\". But it's\n    probably a bad idea, if only because it would not be consistently\n    applied to repos on the other side of git://, http://, or ssh\n    sessions.\n\n    So the sanest fix, if we want submodules to inherit the command-line\n    config, would be to drop GIT_CONFIG_PARAMETERS from local_repo_env,\n    and have the transport code suppress it manually.\n"},{"id":"257455","messageId":"54FEB1CA.7020204@web.de","threadId":"38709","inReplyTo":"20150309074339.GA31866@peff.net","subject":"Re: Bug? git submodule add SSL certificate problem: unable to get local issuer certificate","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2015-03-10T08:56:42Z","receivedAt":"2015-03-10T08:56:42Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 09.03.2015 um 20:43 schrieb Jeff King:\n> On Thu, Mar 05, 2015 at 04:20:10PM +0100, Aschemann Gerd wrote:\n>\n>> 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:\n>>\n>>    $ git -c http.sslverify=false submodule add https://example.com/git/xxx.git\n>>    Cloning into 'xxx'...\n>>    fatal: unable to access 'https://example.com/git/xxx.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none\n>>    Clone of 'https://example.com/git/xxx.git' into submodule path 'xxx' failed\n>>\n>> Performing a simple clone works well:\n>>\n>>    $ git -c http.sslverify=false clone https://example.com/git/xxx.git\n>>    Cloning into 'xxx'...\n>>    Password for 'https://example.com':\n>\n> I think the problem is that the submodule code wipes all \"local\"\n> environment variables before executing the submodule clone, and that\n> includes the variable containing command-line config.\n>\n> Config like this is in a funny boat. We do not want it to cross\n> transport boundaries, so that if we run:\n>\n>    git -c foo=bar clone /some/local/path\n>\n> the process serving /some/local/path should not see the \"foo\" option[1].\n> But for submodules in the same repository, keeping the shared config is\n> probably more reasonable (I can imagine a config variable that you might\n> want to behave differently between the submodule and the main project,\n> but I could not think of any off-hand, and I expect it would be a rare\n> exception).\n>\n> Submodule folks (cc'd) may have opinions.\n\nI tend to rather not share configs. While I agree that for the example\nwhich started this it would be correct to simply pass http.sslverify,\nthat doesn't always make sense (e.g. it never does for a setting like\ncore.worktree).\n\nWe already have two options for submodule add and update that are\npassed to the clone command (--reference & --depth), maybe it is time\nto add another one for passing config options to clone (which then get\nset permanently in the submodule's config).\n\n> -Peff\n>\n> [1] This behavior comes from 655e8d9 (do not pass \"git -c foo=bar\"\n>      params to transport helpers, 2010-08-24), and the original\n>      discussion is here:\n>\n>        http://thread.gmane.org/gmane.comp.version-control.git/154241/focus=154255\n>\n>      I am tempted to simply drop the transport-layer blocking of config\n>      options. It is not buying us anything security-wise, and it could\n>      actually be convenient to pass options to the \"other side\". But it's\n>      probably a bad idea, if only because it would not be consistently\n>      applied to repos on the other side of git://, http://, or ssh\n>      sessions.\n>\n>      So the sanest fix, if we want submodules to inherit the command-line\n>      config, would be to drop GIT_CONFIG_PARAMETERS from local_repo_env,\n>      and have the transport code suppress it manually.\n>\n"},{"id":"258242","messageId":"20150321132259.GA11843@peff.net","threadId":"38709","inReplyTo":"54FEB1CA.7020204@web.de","subject":"Re: Bug? git submodule add SSL certificate problem: unable to get local issuer certificate","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-03-21T13:22:59Z","receivedAt":"2015-03-21T13:22:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 10, 2015 at 09:56:42PM +1300, Jens Lehmann wrote:\n\n> >Config like this is in a funny boat. We do not want it to cross\n> >transport boundaries, so that if we run:\n> >\n> >   git -c foo=bar clone /some/local/path\n> >\n> >the process serving /some/local/path should not see the \"foo\" option[1].\n> >But for submodules in the same repository, keeping the shared config is\n> >probably more reasonable (I can imagine a config variable that you might\n> >want to behave differently between the submodule and the main project,\n> >but I could not think of any off-hand, and I expect it would be a rare\n> >exception).\n> >\n> >Submodule folks (cc'd) may have opinions.\n> \n> I tend to rather not share configs. While I agree that for the example\n> which started this it would be correct to simply pass http.sslverify,\n> that doesn't always make sense (e.g. it never does for a setting like\n> core.worktree).\n> \n> We already have two options for submodule add and update that are\n> passed to the clone command (--reference & --depth), maybe it is time\n> to add another one for passing config options to clone (which then get\n> set permanently in the submodule's config).\n\nSorry, I missed this earlier, as it fell into a spam trap.\n\nWhat you're proposing does make sense to me. We already have \"git clone\n-c\", so I think it would just be a matter of passing along that option\nin the submodule code.\n\n-Peff\n"}]}