found 573736 git-core/1:1.7.0.3-1
severity 573736 important
thanks

Thorsten Glaser wrote:

> On a sid system:
> 
>    git clone https://alioth.debian.org/anonscm/git/pkg-wml/pkg-wml.git
> Initialized empty Git repository in /home/tg/shared/pkg-wml/.git/
> error: server certificate verification failed. CAfile: 
> /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing 
> https://alioth.debian.org/anonscm/git/pkg-wml/pkg-wml.git/info/refs
> 
> fatal: HTTP request failed

Same here.  Workaround:

 $ GIT_SSL_NO_VERIFY=1 git clone 
https://alioth.debian.org/anonscm/git/pkg-wml/pkg-wml.git
 Initialized empty Git repository in /tmp/pkg-wml/.git/
 warning: You appear to have cloned an empty repository.

You can make the workaround permanent with

 echo '[http] sslverify = false' >> ~/.gitconfig

with the obvious associated collateral damage.  See git-config(1) for
more details.

> On the same system:
> 
> $ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect 
> alioth.debian.org:443
[...]
> subject=/O=Debian/CN=alioth.debian.org/emailaddress=ad...@alioth.debian.org
> issuer=/O=Debian/CN=ca.debian.org/emailaddress=debian-ad...@debian.org
[...]
> So this is not a problem with the ca bundle. I think this is
> because it doesn't correctly validate the chain or something.
> Same on Lenny, FWIW.

Debian git uses libcurl3-gnutls for HTTP support.  Sadly I know almost
nothing about these things.  With gnutls-bin installed,

  gnutls-cli -p 443 <host>

tells me that

- The hostname in the certificate matches '<host>'
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted

and it does not abort, for just about any host I try.

Git uses the following settings (from http.c):

 if (!curl_ssl_verify) {
        curl_easy_setopt(result, CURLOPT_SSL_VERIFYPEER, 0);
        curl_easy_setopt(result, CURLOPT_SSL_VERIFYHOST, 0);
 } else {
        /* Verify authenticity of the peer's certificate */
        curl_easy_setopt(result, CURLOPT_SSL_VERIFYPEER, 1);
        /* The name in the cert must match whom we tried to connect */
        curl_easy_setopt(result, CURLOPT_SSL_VERIFYHOST, 2);
 }

Ramakrishnan, do these settings look sane to you?  Does curl interpret
these settings the same way when using the OpenSSL backend (as most
people elsewhere do) and when using GnuTLS backend (as Debian does for
licensing reasons)?

Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to