Error setting certificate verify locations
vogella
do you have already a bug report for the issue that during a git clone
via https the following message is giving:
--------------
error: error setting certificate verify locations:
CAfile: /bin/curl-ca-bundle.crt
CApath: none
while accessing
--------------
If yes can you please give me the bug URL so that I can subscribe?
I got the solution from http://github.com/blog/642-smart-http-support
and summerized it http://www.vogella.de/blog/2010/08/09/git-https/
Best regards, Lars
Johannes Schindelin
On Mon, 9 Aug 2010, vogella wrote:
> do you have already a bug report for the issue that during a git clone
> via https the following message is giving:
> --------------
> error: error setting certificate verify locations:
> CAfile: /bin/curl-ca-bundle.crt
> CApath: none
> while accessing
> --------------
I saw this once, too, but did not have time to fix it.
> If yes can you please give me the bug URL so that I can subscribe?
>
> I got the solution from http://github.com/blog/642-smart-http-support
Sorry. I just spent a couple of minutes trying to find the solution on
that website. There are tons of comments. Some claim to solve the thing,
but they are not portable, or do not work at all. If there is one, it is
not easy to find, and you would have better summarized it (since you did
not, the time spent on the search reduced my readiness to work on this bug
dramatically).
Ciao,
Johannes
Erik Faye-Lund
> Hello,
>
> do you have already a bug report for the issue that during a git clone
> via https the following message is giving:
> --------------
> error: error setting certificate verify locations:
> CAfile: /bin/curl-ca-bundle.crt
> CApath: none
> while accessing
> --------------
>
This error puzzle me a bit, because:
1) my /etc/gitconfig sets sslCAinfo to
"/mingw/bin/curl-ca-bundle.crt", not "/bin/curl-ca-bundle.crt"
2) either way, it looks like libcurl gets an msys-path in my setup.
The odd part is that this actually seems to work for me -- shouldn't
our libcurl only deal with Win32-paths?
Johannes Schindelin
It's Git, not cURL, that handles that information. And this is the commit
that should fix the behavior (note the date...):
Ciao,
Dscho
Erik Faye-Lund
Thanks for that sanity-check. But now I am even more puzzled; why
should Git care at all about MSYS-paths if it's not an MSYS
application? Is this something that is needed in order to supply the
same gitconfig-file across all installations? In that case, shouldn't
something like "git config --system /mingw/bin/curl-ca-bundle.crt"
right after installation translate the path to the installed path for
us (ie let bash do the translation)? This might cause some problems
for PortableGit, though...
vogella
you might have overseen that I did write a summary (see my original
post) in http://www.vogella.de/blog/2010/08/09/git-https/
Best regards, Lars
On Aug 10, 11:23 am, Johannes Schindelin <Johannes.Schinde...@gmx.de>
wrote:
>
> On Mon, 9 Aug 2010, vogella wrote:
> > do you have already a bug report for the issue that during a git clone
> > via https the following message is giving:
> > --------------
> > error: error setting certificate verify locations:
> > CAfile: /bin/curl-ca-bundle.crt
> > CApath: none
> > while accessing
> > --------------
>
> I saw this once, too, but did not have time to fix it.
>
> > If yes can you please give me the bug URL so that I can subscribe?
>
Johannes Schindelin
How would you specify the location of a file that is inside the MSys fake
root directory otherwise?
> Is this something that is needed in order to supply the same
> gitconfig-file across all installations? In that case, shouldn't
> something like "git config --system /mingw/bin/curl-ca-bundle.crt" right
> after installation translate the path to the installed path for us (ie
> let bash do the translation)? This might cause some problems for
> PortableGit, though...
It might cause problems for PortableGit, and it might cause problems for
the msysGit installer (and every script that needs to establish a
temporary fake root, e.g. to overcome file lock problems with in-use .dll
files).
As to me, I am puzzled why I got the problem even if I was runnnig a
current msysGit, as the commit I referenced should have fixed the problem.
No time to investigate, though,
Dscho
Johannes Schindelin
On Tue, 10 Aug 2010, Lars Vogel wrote:
> 2010/8/10 Johannes Schindelin <Johannes....@gmx.de>:
> you might have overseen that I did write a summary (see my original
> post) in http://www.vogella.de/blog/2010/08/09/git-https/
Indeed, I missed it. Let me summarize: you propose to set the absolute
DOS-style path. Probably after installation, as Erik suggested. As I
suggested, this might lead to more problems than it solves, and I'd like
the code introduced in the commit I referenced in the mail to Erik to be
fixed.
But I simply have no time, what with a runaway thread on the Git mailing
list costing me times and nerves.
Ciao,
Dscho
Lars Vogel
> DOS-style path. Probably after installation, as Erik suggested. As I
> suggested, this might lead to more problems than it solves, and I'd like
> the code introduced in the commit I referenced in the mail to Erik to be
> fixed.
Yes, I did this change after installation. I wanted to give a summary
what can fix the error as the original thread had lots of people
running in the same issue.
Erik Faye-Lund
<Johannes....@gmx.de> wrote:
>> Is this something that is needed in order to supply the same
>> gitconfig-file across all installations? In that case, shouldn't
>> something like "git config --system /mingw/bin/curl-ca-bundle.crt" right
>> after installation translate the path to the installed path for us (ie
>> let bash do the translation)? This might cause some problems for
>> PortableGit, though...
>
> It might cause problems for PortableGit,
It certainly does. I don't care much about Portable Git, but others
probably do :P
> and it might cause problems for
> the msysGit installer
I don't think it's a problem for the installer - the installer should
already have the permissions required to write to the file, and
processes inherit their elevation-level from their parents.
> (and every script that needs to establish a
> temporary fake root, e.g. to overcome file lock problems with in-use .dll
> files).
This might be an issue, indeed.
> As to me, I am puzzled why I got the problem even if I was runnnig a
> current msysGit, as the commit I referenced should have fixed the problem.
>
> No time to investigate, though,
I'm not so puzzled about that part; the first thing system_path() does
is to check if the input is an absolute path, and return it's input
unmodified. And the default string is an absolute path as far as
is_absolute_path() is concerned: it starts with a forward slash.
To fix this logic, you'd probably want to hoist out most of the
system_path() logic into a helper function, and use that instead. I
think that would work for our default setup, but if someone would like
to specify other sslCAinfo-paths, they might run into problems.
One alternative could be to not treat paths that begin with a forward
slash as an absolute path on Windows at all, but this probably has
other negative side-effects.
Johannes Schindelin
On Tue, 10 Aug 2010, Erik Faye-Lund wrote:
> On Tue, Aug 10, 2010 at 3:23 PM, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
>
> > and it might cause problems for the msysGit installer
>
> I don't think it's a problem for the installer
... but it does, because it is establishing a fake root just like ...
> > (and every script that needs to establish a
> > temporary fake root, e.g. to overcome file lock problems with in-use .dll
> > files).
>
> This might be an issue, indeed.
And it is.
> > As to me, I am puzzled why I got the problem even if I was runnnig a
> > current msysGit, as the commit I referenced should have fixed the
> > problem.
> >
> > No time to investigate, though,
>
> I'm not so puzzled about that part; the first thing system_path() does
> is to check if the input is an absolute path, and return it's input
> unmodified. And the default string is an absolute path as far as
> is_absolute_path() is concerned: it starts with a forward slash.
>
> To fix this logic, you'd probably want to hoist out most of the
> system_path() logic into a helper function, and use that instead. I
> think that would work for our default setup, but if someone would like
> to specify other sslCAinfo-paths, they might run into problems.
>
> One alternative could be to not treat paths that begin with a forward
> slash as an absolute path on Windows at all, but this probably has other
> negative side-effects.
The problem is that I usually test my patches before putting them onto
4msysgit.git's 'devel' branch. As I did with this one. So it used to work.
Ciao,
Dscho