Top posting a summary..
The root cause was not a Windows Credential Store issue, rather it was
that of the HTTPS Certificate Authority !

And the source of that problem is that the http.sslcainfo path is:
(a) written *nix style at a path that is rooted (starts with the *nix
root directory /)
(b) held in the --system config, which in *nix is in /etc/.. (i.e. also
rooted)
(c) and I am on windows which has not concept of a single root!

Net effect is that, depending on which bash/cmd shell you start, you get
a different windows directory mapped to the *nix root, thus presenting
different locations for the Certificate Authority (CA) bundle.

On windows, the root path is determined by the starting bash/cmd
routine.

Ultimately I had an incompatible CAfile for the compiled Git version in
the bash I'd started (I was allegedly in 'msysgit 1.9.5', but had
compiled a newer version of git with a newer curl/openSSL.) Swapping to
a different Git/bash (g4w) that I hadn't hacked, solved it.
--
Philip

more commentary in-line.

From: "Philip Oakley" <philipoak...@iee.org>
Sent: Saturday, July 11, 2015 6:14 PM
From: "Philip Oakley" <philipoak...@iee.org>
Sent: Saturday, July 11, 2015 11:32 AM
I've not used any of the git credentials before, but now I'm looking
to use an https repo address and have tripped over the cliff of
knowledge into the swamp below with regard to setting up a credential
store....

I'm still on XP.

I have git version 2.3.1 (from the new SDK)

My config has:
credential.helper=!"C:/Program
Files/GitExtensions/GitCredentialWinStore/git-credential-winstore.exe"
(which is installed at that location)

and recently added:
remote.g4w-git.url=https://github.com/git-for-windows/git.git
remote.dscho-git.url=https://github.com/dscho/git.git
(note that both are https, while all my other remotes are mainly
git://, with a few http://)

I have a little script "BringGitUptodate.sh" for collecting all the
disparate development threads of Git (Upstream, Msysgit & G4W-SDK
;-), so I've now included these remotes but often get this error.

When I fetch the two new remotes I get:
fetch g4w-git & dscho-git =====
fatal: unable to access
'https://github.com/git-for-windows/git.git/': error setting
certificate verify locations:

Misunderstanding #1: this verification failure is not about my username
& password at github, it's about checking that I've reached github
securely.

 CAfile: /mingw/bin/curl-ca-bundle.crt
 CApath: none
fatal: unable to access 'https://github.com/dscho/git.git/': error
setting certificate verify locations:
 CAfile: /mingw/bin/curl-ca-bundle.crt
 CApath: none


These errors may not be credentail related, rather its the HTTPS
certificate authority that isn't working.

I see two possible relevant, but closed, issues on g4w:
https://github.com/git-for-windows/git/issues/72, &
https://github.com/git-for-windows/git/issues/165.


Most of the google searching has shown ssh setups, and I've not found
anything that shows the way into the system (aka "Speak, Friend, and
Enter").

What [program/command] should I run first?
What should I expect to enter/enable first?
What pitfalls should I be wary of? (hence this email;-)

Any advice or guidance for this first dumb user [1] step would be
greatly appreciated.

regards

Philip

[1] Unskilled and unaware of it: Kruger & Dunning
a)
http://psych.colorado.edu/~vanboven/teaching/p7536_heurbias/p7536_readings/kruger_dunning.pdf
b) https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
c) 'teach the bottom quartile'...

I've confirmed that the curl-ca-bundle.crt actually has content, and

Misunderstanding #2: I merely tried one file, rather than seeing how
many I had, which would have given a clue that I had different setups.

tried:

Philip@PHILIPOAKLEY /mingw/bin (master)
$ curl -V
curl 7.41.0 (i386-pc-win32) libcurl/7.41.0 OpenSSL/0.9.8zf zlib/1.2.8
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
pop3 pop3s rtsp smtp smtps tel
net tftp
Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz

Philip@PHILIPOAKLEY /mingw/bin (master)
$ pwd -W
C:/msysgit195/mingw/bin

meanwhile, elsewhere (g4w bash)
Philip@PhilipOakley MINGW32 /

$ curl -V

curl 7.42.1 (i686-w64-mingw32) libcurl/7.42.1 OpenSSL/1.0.2a zlib/1.2.8 libidn/1.30 libssh2/1.5.0 librtmp/2.3

Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp

Features: IDN Largefile SSPI Kerberos SPNEGO NTLM SSL libz TLS-SRP

Philip@PhilipOakley MINGW32 /

$ pwd -W

C:/git-sdk-32

ie. a quite different / newer signature

Philip@PHILIPOAKLEY /mingw/bin (master)
$ curl https://github.com/dscho/git.git/
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

Philip@PHILIPOAKLEY /mingw/bin (master)
$ curl https://github.com/git-for-windows/git.git/
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

---
the same web addresses do work in Chrome (that is they get to display
the relevant repos), so I'm not sure what to make of the 301 (not my
area of expertise;-).

my config also has:
http.sslcainfo=/mingw/bin/curl-ca-bundle.crt

Misunderstanding #3: Failure to note which config file it was located in
& where it was.
In this case it's the --system config, and that's at an indeterminate
location in the windows file system, despite being rooted in *nix.
I've now added an extra section to the --system config
[self]
location = /c/msysgit195/etc # with the true file path msysgit style
"C:" -> "/c/", etc.

so I can ask
$ git config self.location

and it will tell me which system config file I'm using - which is useful for Windows.

http://stackoverflow.com/questions/3778042/github-error-cloning-my-private-repository
(2010) suggests that the windows style path should be used, but that
could be rather old advice. I've checked that the curl-ca-bundle.crt
is *nix LF endings.


Using the windows path would avoid the lack of a *nix root, so it's one solution.

Thoughts?

Philip



--
You received this message because you are subscribed to the Google Groups "Git for 
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to