Bug#491036: SSL client certificate passphrase support

2015-10-28 Thread Olaf Flebbe
Package: git
Version: 1:2.1.4-2.1
Severity: important
Followup-For: Bug #491036

User Certificates Support works. However, if the certificate (more correctly 
the key of the cert) is encrypted, git fails with a bogus error message:

olaf@nucky:~$ git clone https://xxx.science-computing.de/prot-anon.git
Klone nach 'prot-anon'...
Password for 'cert:home/olaf/mycert.pem': 
fatal: unable to access 'https://xxx.science-computing.de/prot-anon.git/': 
error reading X.509 key or certificate file

if you look at the command with strace you see a bogus write call to fileid -1 
causing the error message above:
>  writev(-1, [{"\25\3\3\0\2\1\0", 7}], 1) = -1 EBADF (Bad file descriptor)

changing the build dependency from libcurl4-gnutls-dev to libcurl4-openssl-dev 
fixes the weird behaviour. It smells like a hidden binary incompatibilty 
between different curl flavours.

raising severity to important, since this makes package unusable for any 
environment secured by user certificates. BTW, centos and SuSE does not show 
this bug. Maybe the bug has to be fixed in libcurl4-gnutls itself

--- git-2.1.4/debian/control2014-12-20 03:13:38.0 +0100
+++ control 2015-10-28 17:55:35.679424672 +0100
@@ -4,7 +4,7 @@
 Maintainer: Gerrit Pape 
 Uploaders: Jonathan Nieder 
 Build-Depends: libz-dev, libpcre3-dev, gettext,
- libcurl4-gnutls-dev, libexpat1-dev,
+ libcurl4-openssl-dev, libexpat1-dev,
  subversion, libsvn-perl, libyaml-perl,
  tcl,
  libhttp-date-perl | libtime-modules-perl,



-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages git depends on:
ii  git-man  1:2.1.4-2.1
ii  libc62.19-18
ii  libcurl3-gnutls  7.38.0-4+deb8u2
ii  liberror-perl0.17-1.1
ii  libexpat12.1.0-6+deb8u1
ii  libpcre3 2:8.35-3.3
ii  perl-modules 5.20.2-3+deb8u1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages git recommends:
ii  less 458-3
ii  openssh-client [ssh-client]  1:6.7p1-5
ii  patch2.7.5-1
ii  rsync3.1.1-3

Versions of packages git suggests:
ii  gettext-base  0.19.3-2
pn  git-arch  
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information



Bug#491036: SSL client certificate passphrase support

2008-07-15 Thread Joe Rayhawk
Package: git-core
Version: 1.5.6.2-1
Severity: wishlist  



libcurl compiled against gnutls does not support passphrases on SSL
client keys. libcurl compiled against openssl does just fine. This makes
client keys rather impractical to use with Debian's git-core.

Testing this can be done with the following commands:

curl -O http://hitler.omgwallhack.org/ssltesting/usercert/chump.pem
curl -O http://hitler.omgwallhack.org/ssltesting/testca.crt
curl -O http://hitler.omgwallhack.org/ssltesting/usercert/chump-password.pem
GIT_SSL_CAINFO=testca.crt GIT_SSL_CERT=chump.pem git clone 
https://hitler.omgwallhack.org/ssltesting/ssltest.git/
rm -rf ssltest
GIT_SSL_CAINFO=testca.crt GIT_SSL_CERT=chump-password.pem git clone 
https://hitler.omgwallhack.org/ssltesting/ssltest.git/
rm -rf ssltest

Curl, compiled against openssl, does the *right* thing:

curl -E chump.pem --cacert testca.crt https://hitler.omgwallhack.org/ssltesting/
curl -E chump-password.pem:password --cacert testca.crt 
https://hitler.omgwallhack.org/ssltesting/

(If anyone happens to want to recreate the server environment,
http://hitler.omgwallhack.org/ssltesting/ca.sh will probably help you
out.)

I don't know what the solution would be for this since I don't really
know why git-core Depends: libcurl3-gnutls (= 7.16.2-1) in Debian in
the first place. Manually replacing libcurl-gnutls.so.4.1.0 with
libcurl.so.4.1.0 didn't have any other engaging consequences to git
besides solving this bug for me, for what it's worth.

I've tested a patch that exposes CURLOPT_SSLKEY within git. This library
feature appears to do nothing in libcurl[3|4]-gnutls, so I wouldn't
suggest anybody else try the same.


signature.asc
Description: Digital signature