Debian Bug report logs - #594150
"no useful error message if server attempts insecure renegotiation"

version graph

Package: libcurl3-gnutls; Maintainer for libcurl3-gnutls is Alessandro Ghedini <ghedo@debian.org>; Source for libcurl3-gnutls is src:curl.

Reported by: Johannes Ernst <johannes.ernst@gmail.com>

Date: Tue, 24 Aug 2010 03:36:01 UTC

Severity: important

Tags: fixed-upstream

Merged with 594153

Found in versions curl/7.21.1-1, curl/7.21.0-1

Fixed in version 7.21.3-1

Done: Alessandro Ghedini <al3xbio@gmail.com>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#594150; Package apt-transport-https. (Tue, 24 Aug 2010 03:36:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Johannes Ernst <johannes.ernst@gmail.com>:
New Bug report received and forwarded. Copy sent to APT Development Team <deity@lists.debian.org>. (Tue, 24 Aug 2010 03:36:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Johannes Ernst <johannes.ernst@gmail.com>
To: submit@bugs.debian.org
Subject: apt-transport-https fail after squeeze upgrade
Date: Mon, 23 Aug 2010 20:25:00 -0700
Package: apt-transport-https
Version: 0.7.25.3
Severity: grave
Justification: renders package unusable

*** Please type your report below this line ***

I have an apt https setup with client certs that has been working fine for lenny. After upgrading to squeeze, it fails.
Has anything changed in the configuration? I'm not really able to find any relevant documentation ...

I've created a test setup which is documented at:
    http://apt-test.aviatis.com/
It runs apt-cacher (so you know what it will produce if it does ...). Clients need to specify a client cert to get access.
Client config instructions are at that URL. Please e-mail me with any questions or requests for changes in the setup.

Details:

----

Error message on client (that runs apt):

Err https://FOO foo/main Packages
 SSL connection timeout
W: Failed to fetch https://FOO/FOO/dists/foo/main/binary-i386/Packages.gz  SSL connection timeout

----

SSL log on the server (that runs apt-cacher):

squeeze:
[14/Aug/2010:19:05:19 +0000] 192.168.1.5 SSLv3 - - -

compare with lenny:
[14/Aug/2010:10:11:06 +0000] 192.168.1.6 SSLv3 DHE-RSA-AES128-SHA FOO FOO.com

----

/etc/apt/apt.conf.d/client-cert:

Acquire {
 https {
       Verify-Peer "false";
       CaPath  "/etc/ssl/certs";
       Verify-Host "false";
       AllowRedirect  "true";

       SslCert "/etc/FOO/FOO.crt";
       SslKey  "/etc/FOO/FOO.key";
       SslForceVersion "SSLv3"; // Somehow it does not work unless we do this (this is a lenny comment, but changing it does not change matters in squeeze)
 }
}

----

When I use the same client cert files with curl on squeeze, I can access the file that apt fails to access.





Merged 594150 594153. Request was from Thijs Kinkhorst <thijs@debian.org> to control@bugs.debian.org. (Tue, 24 Aug 2010 06:48:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#594150; Package apt-transport-https. (Tue, 24 Aug 2010 11:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Kalnischkies <kalnischkies+debian@gmail.com>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Tue, 24 Aug 2010 11:15:03 GMT) Full text and rfc822 format available.

Message #12 received at 594150@bugs.debian.org (full text, mbox):

From: David Kalnischkies <kalnischkies+debian@gmail.com>
To: Johannes Ernst <johannes.ernst@gmail.com>, 594150@bugs.debian.org
Cc: control <control@bugs.debian.org>
Subject: Re: Bug#594150: apt-transport-https fail after squeeze upgrade
Date: Tue, 24 Aug 2010 13:10:25 +0200
package apt-transport-https libcurl3-gnutls
reassign 594150 libcurl3-gnutls 7.21.0-1
found 594150 7.21.1-1
affects 594150 apt-transport-https
retitle 594150 CURLOPT_TIMEOUT defaults to zero seconds
thanks

apt-transport-https doesn't set CURLOPT_TIMEOUT anymore
in its squeeze version while it does in its lenny version.
(see #497983 for why)

It looks like the option defaults to 0 in the affected versions
as setting CURLOPT_TIMEOUT explicit to 0 has the same result.
Higher limits obviously let it work as expected.

Tests on an older ubuntu release with
Upgrade: libcurl3-gnutls:i386 (7.19.7-1ubuntu1, 7.21.0-1ubuntu1)
shows that this wasn't present in at least 7.19.7-1ubuntu1.
In a debian unstable environment both versions (unstable, testing)
were tested and affected (stable was not tested, but as it is older
than the tested good-known ubuntu version i guess it is good too).


Thanks btw Johannes Ernst for your bugreport and especially
for providing a testarchive!


His error message in APT is:

> Err https://FOO foo/main Packages
>  SSL connection timeout
> W: Failed to fetch https://FOO/FOO/dists/foo/main/binary-i386/Packages.gz  SSL connection timeout

curl used with verbose option prints:
( -o Debug::Acquire::https=1 )

* About to connect() to apt-test.aviatis.com port 443 (#0)
*   Trying 204.145.147.227... * connected
* Connected to apt-test.aviatis.com (204.145.147.227) port 443 (#0)
* found 141 certificates in /etc/ssl/certs/ca-certificates.crt
*        server certificate verification SKIPPED
*        common name: apt-test.aviatis.com (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #1
*        subject: C=US,ST=CA,O=apt-test.aviatis.com,CN=apt-test.aviatis.com
*        start date: Mon, 23 Aug 2010 04:23:41 GMT
*        expire date: Sun, 19 May 2013 04:23:41 GMT
*        issuer: C=US,ST=CA,O=apt-test.aviatis.com,CN=apt-test.aviatis.com
*        compression: NULL
*        cipher: AES-128-CBC
*        MAC: SHA1
> GET /apt-cacher/ftp.us.debian.org/debian/dists/squeeze/Release.gpg HTTP/1.1
User-Agent: Debian APT-CURL/1.0 (0.7.26~exp6)
Host: apt-test.aviatis.com
Accept: */*
Cache-Control: max-age=0

* SSL connection timeout
* Closing connection #0
[… same output for the next requested file … ]


Best regards

David Kalnischkies




Bug reassigned from package 'apt-transport-https' to 'libcurl3-gnutls'. Request was from David Kalnischkies <kalnischkies+debian@gmail.com> to control@bugs.debian.org. (Tue, 24 Aug 2010 11:15:05 GMT) Full text and rfc822 format available.

Bug No longer marked as found in versions apt/0.7.25.3. Request was from David Kalnischkies <kalnischkies+debian@gmail.com> to control@bugs.debian.org. (Tue, 24 Aug 2010 11:15:06 GMT) Full text and rfc822 format available.

Bug Marked as found in versions curl/7.21.0-1. Request was from David Kalnischkies <kalnischkies+debian@gmail.com> to control@bugs.debian.org. (Tue, 24 Aug 2010 11:15:07 GMT) Full text and rfc822 format available.

Bug Marked as found in versions curl/7.21.1-1. Request was from David Kalnischkies <kalnischkies+debian@gmail.com> to control@bugs.debian.org. (Tue, 24 Aug 2010 11:15:09 GMT) Full text and rfc822 format available.

Added indication that 594150 affects apt-transport-https Request was from David Kalnischkies <kalnischkies+debian@gmail.com> to control@bugs.debian.org. (Tue, 24 Aug 2010 11:15:10 GMT) Full text and rfc822 format available.

Changed Bug title to 'CURLOPT_TIMEOUT defaults to zero seconds' from 'apt-transport-https fail after squeeze upgrade' Request was from David Kalnischkies <kalnischkies+debian@gmail.com> to control@bugs.debian.org. (Tue, 24 Aug 2010 11:15:12 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>:
Bug#594150; Package libcurl3-gnutls. (Sat, 13 Nov 2010 21:57:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Steve M. Robbins" <steve@sumost.ca>:
Extra info received and forwarded to list. Copy sent to Ramakrishnan Muthukrishnan <rkrishnan@debian.org>. (Sat, 13 Nov 2010 21:57:06 GMT) Full text and rfc822 format available.

Message #29 received at 594150@bugs.debian.org (full text, mbox):

From: "Steve M. Robbins" <steve@sumost.ca>
To: Johannes Ernst <johannes.ernst@gmail.com>, David Kalnischkies <kalnischkies+debian@gmail.com>
Cc: 594150@bugs.debian.org, 594153@bugs.debian.org
Subject: CURLOPT_TIMEOUT defaults to zero seconds
Date: Sat, 13 Nov 2010 15:53:17 -0600
[Message part 1 (text/plain, inline)]
Hi,

Reading through this bug report, I understand that the change in
apt-transport-https (not setting CURLOPT_TIMEOUT) broke apt-get.

David Kalnischkies reassigned this to libcur3-gnutls stating that the
default value for this option is 0 and implying that this is a bug.

Does curl really treat the default value as 0 seconds timeout on the
connection?  Or does it treat 0 as unlimited (i.e. no timeout)?  The
manpage for curl_easy_setopt is unclear on this.

I'm downloading the curl sources to check, but I'd be somewhat
surprised if this were the bug since it would affect basically all
usage of curl and would have been detected by others immediately.

Moreover, the notes on http://apt-test.aviatis.com/ say:

    Intended behavior: apt-get update and all other apt commands work
    as long as the specified client-side key/cert is given. Access is
    denied if they are not given.

    Actual observed behavior: on lenny, it works as intended. On
    squeeze, the TCP connection is dropped and there are no successful
    invocations of apt.

    Noteworthy: on squeeze, curl seems to be able to access the files
    successfully with the same key material. Try: curl
    https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/Release
    -k --cert
    /etc/apt/client-certs/test-client.apt-test.aviatis.com.crt --key
    /etc/apt/client-certs/test-client.apt-test.aviatis.com.key

So I'm left wondering whether the bug really is in apt-transport-https
after all?

Cheers,
-Steve
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>:
Bug#594150; Package libcurl3-gnutls. (Sat, 13 Nov 2010 22:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Stenberg <daniel@haxx.se>:
Extra info received and forwarded to list. Copy sent to Ramakrishnan Muthukrishnan <rkrishnan@debian.org>. (Sat, 13 Nov 2010 22:33:03 GMT) Full text and rfc822 format available.

Message #34 received at 594150@bugs.debian.org (full text, mbox):

From: Daniel Stenberg <daniel@haxx.se>
To: "Steve M. Robbins" <steve@sumost.ca>, 594150@bugs.debian.org
Cc: Johannes Ernst <johannes.ernst@gmail.com>, David Kalnischkies <kalnischkies+debian@gmail.com>, 594153@bugs.debian.org, debian-bugs-dist@lists.debian.org, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>
Subject: Re: Bug#594150: CURLOPT_TIMEOUT defaults to zero seconds
Date: Sat, 13 Nov 2010 23:08:43 +0100 (CET)
On Sat, 13 Nov 2010, Steve M. Robbins wrote:

> Does curl really treat the default value as 0 seconds timeout on the 
> connection?  Or does it treat 0 as unlimited (i.e. no timeout)?  The manpage 
> for curl_easy_setopt is unclear on this.

curl treats a TIMEOUT explicitly set to 0 as a way to disable any previous set 
timeouts and it goes back to the internal defaults - it is the same as not 
usig CURLOPT_TIMEOUT at all.

Internal default is pretty much no timeout at all (the situation is a bit more 
complicated than so, but in general you can consider it to be without 
timeout).

I have no idea where this bug belongs, but I'm not aware of any bug like this 
in curl.

-- 

 / daniel.haxx.se




Information forwarded to debian-bugs-dist@lists.debian.org, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>:
Bug#594150; Package libcurl3-gnutls. (Sat, 13 Nov 2010 23:30:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon McVittie <smcv@debian.org>:
Extra info received and forwarded to list. Copy sent to Ramakrishnan Muthukrishnan <rkrishnan@debian.org>. (Sat, 13 Nov 2010 23:30:06 GMT) Full text and rfc822 format available.

Message #39 received at 594150@bugs.debian.org (full text, mbox):

From: Simon McVittie <smcv@debian.org>
To: "Steve M. Robbins" <steve@sumost.ca>, 594150@bugs.debian.org
Cc: Johannes Ernst <johannes.ernst@gmail.com>, David Kalnischkies <kalnischkies+debian@gmail.com>, 594153@bugs.debian.org, Daniel Stenberg <daniel@haxx.se>
Subject: Re: Bug#594150: CURLOPT_TIMEOUT defaults to zero seconds
Date: Sat, 13 Nov 2010 23:27:43 +0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

(Ramakrishnan, would you mind pushing recent versions of curl to git.debian.org?
The last thing there seems to be 7.20.1-2 with the tag missing.
If you've lost the git history since then, I have a tree of git-import-dsc
imports (plus some random hacking on the master branch to pin down which
error we're seeing here) at <http://git.debian.org/?p=users/smcv/qa/curl.git>.)

On Sat, 13 Nov 2010 at 15:53:17 -0600, Steve M. Robbins wrote:
> Does curl really treat the default value as 0 seconds timeout on the
> connection?  Or does it treat 0 as unlimited (i.e. no timeout)?  The
> manpage for curl_easy_setopt is unclear on this.

Looking at the relevant source code, it seems to be intended to be
no timeout. This seems to need quite a few special cases, though, so it
wouldn't surprise me if one had been forgotten, particularly in the
less-often-used gnutls backend.

>     Noteworthy: on squeeze, curl seems to be able to access the files
>     successfully with the same key material. Try: curl
>     https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/Release
>     -k --cert
>     /etc/apt/client-certs/test-client.apt-test.aviatis.com.crt --key
>     /etc/apt/client-certs/test-client.apt-test.aviatis.com.key

However, curl(1) on Debian uses the OpenSSL variant of the library,
whereas apt-transport-https uses the GNUTLS one. By way of background info
for upstream: the binary package builds curl twice, once for each variant,
in debian/build and debian/build-gnutls (respectively), and packages them
separately; dependent packages choose one or the other according to their
licensing requirements (GPL things, like apt, need the GNUTLS variant).

The build tree in debian/build-gnutls is compiled --without-ssl --with-gnutls
- --without-libssh2, with some build-system patches to make it produce
libcurl-gnutls.so. There don't seem to be code changes, though, so hopefully
you might be able to reproduce this with an unpatched build with similar
./configure arguments.

While in the build tree of Debian's curl packages, you can test either version
with the corresponding curl command-line tool, even though the GNUTLS
variant isn't actually going to be installed. Hopefully I'm driving it
correctly here:

# OpenSSL backend, zero timeout, succeeds
./debian/build/src/curl -k https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/Release --cert ../test-client.apt-test.aviatis.com.crt --key ../test-client.apt-test.aviatis.com.key

# OpenSSL backend, 10 second timeout, succeeds
./debian/build/src/curl -m10 -k https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/Release --cert ../test-client.apt-test.aviatis.com.crt --key ../test-client.apt-test.aviatis.com.key

# GNUTLS backend, zero timeout, fails
./debian/build-gnutls/src/curl -k https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/Release --cert ../test-client.apt-test.aviatis.com.crt --key ../test-client.apt-test.aviatis.com.key
curl: (28) SSL connection timeout

# GNUTLS backend, 10 second timeout, fails differently!
./debian/build-gnutls/src/curl -m10 -k https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/Release --cert ../test-client.apt-test.aviatis.com.crt --key ../test-client.apt-test.aviatis.com.key
curl: (28) gnutls_handshake() failed: Decryption has failed.

It turns out that the error in the "GNUTLS, zero timeout" test is the *second*
occurrence of this error message in lib/gtls.c handshake() (the one marked
as "g2" in my git branch referenced above). Curl_timeleft() returns 0, and
Curl_socket_ready() also returns 0.

I ran out of brain at this point, I'm afraid... but hopefully this gives
someone a useful clue?

Regards,
    Simon
-----BEGIN PGP SIGNATURE-----

iQIVAwUBTN8e6E3o/ypjx8yQAQjV8g/+IJ+O/B5vf015+UKH1ZgvnBdQYEzddPMQ
YIOS082feEJzVBS0JkeJbjsXGjcbC65Z8JCUcNav5QPu7js7I2iuqV9Pn21v9TNX
JOEDxEQSQL1kWyqVUxES595FuVVtwuVT8+0HJn2R7phQuL/x0Jg4RbzvljquZr3q
sTQidIwHw3rSk/Z26Nrfm68ugBgvlxg2yDxy914hHvBH/uz+nnI+IgSMTG4bT0V4
iNlqT8hYRCpcBhBFbBobel3xQv8qlpKNOQj7aYj2bSe4cz/45Eau+Dzqt6LF3Ydk
XLauxc32GG9KcZFU9/LsZHfuAxoRDjN93PXvp0lvhFsPTJ1Ed2l79M/SXa7AuOBn
9n/BO/vGT5GtsjRc4a4RMwQxWphIrFK3n5YpTLNcLuSVVgbRnEzkNhGz2bGDerDW
WZGaEF4KL82q8afdpWwMllLLm9WbWJt6xlnZI+RE8KWvOhICpvpGlPepFD0EzFNe
D8pH76xLF9q6+p9RSes+mUGX3tA70gUAkwWFFwWFpgiAw90exh6VRiKlPEXm3IsP
t5K6iDWGr1ZWEXD9oKDJZ4Dp06oHozhPTpkTyFopQqA+MjEj8JQu4W4p/xm13g+o
oYpnDmGMcxNVGcfAz8KbAW4Yxwq7iGxFmcgzJvvolg5aC8cpLr0bw6h4tdKmkGFi
QqCMDMq69Rw=
=S9Fd
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>:
Bug#594150; Package libcurl3-gnutls. (Sun, 14 Nov 2010 11:54:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Stenberg <daniel@haxx.se>:
Extra info received and forwarded to list. Copy sent to Ramakrishnan Muthukrishnan <rkrishnan@debian.org>. (Sun, 14 Nov 2010 11:54:03 GMT) Full text and rfc822 format available.

Message #44 received at 594150@bugs.debian.org (full text, mbox):

From: Daniel Stenberg <daniel@haxx.se>
To: Simon McVittie <smcv@debian.org>, 594153@bugs.debian.org
Cc: "Steve M. Robbins" <steve@sumost.ca>, 594150@bugs.debian.org, Johannes Ernst <johannes.ernst@gmail.com>, David Kalnischkies <kalnischkies+debian@gmail.com>, debian-bugs-dist@lists.debian.org, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>
Subject: Re: Bug#594153: Bug#594150: CURLOPT_TIMEOUT defaults to zero seconds
Date: Sun, 14 Nov 2010 12:51:34 +0100 (CET)
On Sat, 13 Nov 2010, Simon McVittie wrote:

> # GNUTLS backend, zero timeout, fails ./debian/build-gnutls/src/curl -k 
> https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/Release 
> --cert ../test-client.apt-test.aviatis.com.crt --key 
> ../test-client.apt-test.aviatis.com.key curl: (28) SSL connection timeout

> It turns out that the error in the "GNUTLS, zero timeout" test is the 
> *second* occurrence of this error message in lib/gtls.c handshake() (the one 
> marked as "g2" in my git branch referenced above). Curl_timeleft() returns 
> 0, and Curl_socket_ready() also returns 0.

This turned out to be a minor bug in curl, yes, and I've fixed it upstream 
now. BUT, I'd like to stress that the timeout problem was just a false track 
and it simply made the error reporting a bit confused and now with my fix curl 
will instead say this:

$ ./src/curl -k 
https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/ 
-v
* About to connect() to apt-test.aviatis.com port 443 (#0)
*   Trying 204.145.147.227... connected
* Connected to apt-test.aviatis.com (204.145.147.227) port 443 (#0)
* found 141 certificates in /etc/ssl/certs/ca-certificates.crt
* 	 server certificate verification SKIPPED
* 	 common name: apt-test.aviatis.com (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #1
* 	 subject: C=US,ST=CA,O=apt-test.aviatis.com,CN=apt-test.aviatis.com
* 	 start date: Mon, 23 Aug 2010 04:23:41 GMT
* 	 expire date: Sun, 19 May 2013 04:23:41 GMT
* 	 issuer: C=US,ST=CA,O=apt-test.aviatis.com,CN=apt-test.aviatis.com
* 	 compression: NULL
* 	 cipher: AES-128-CBC
* 	 MAC: SHA1
> GET /apt-cacher/ftp.us.debian.org/debian/dists/squeeze/ HTTP/1.1
> User-Agent: curl/7.21.3-DEV (i686-pc-linux-gnu) libcurl/7.21.3-DEV 
GnuTLS/2.8.6 zlib/1.2.3.4 c-ares/1.7.4-DEV libidn/1.18 libssh2/1.2.6
> Host: apt-test.aviatis.com
> Accept: */*
>
* gnutls_handshake() failed: Decryption has failed.
* Closing connection #0
curl: (35) gnutls_handshake() failed: Decryption has failed.


... this should be compared with what curl says when instead built to use 
OpenSSL (the exact same code base, the current git version built with some 
extra debug):


$ ./src/curl -k 
https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/ 
-v
* About to connect() to apt-test.aviatis.com port 443 (#0)
*   Trying 204.145.147.227... connected
* Connected to apt-test.aviatis.com (204.145.147.227) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
* 	 subject: C=US; ST=CA; O=apt-test.aviatis.com; CN=apt-test.aviatis.com
* 	 start date: 2010-08-23 04:23:41 GMT
* 	 expire date: 2013-05-19 04:23:41 GMT
* 	 common name: apt-test.aviatis.com (matched)
* 	 issuer: C=US; ST=CA; O=apt-test.aviatis.com; CN=apt-test.aviatis.com
* 	 SSL certificate verify result: self signed certificate (18), 
continuing anyway.
> GET /apt-cacher/ftp.us.debian.org/debian/dists/squeeze/ HTTP/1.1
> User-Agent: curl/7.21.3-DEV (i686-pc-linux-gnu) libcurl/7.21.3-DEV 
OpenSSL/0.9.8o zlib/1.2.3.4 c-ares/1.7.4-DEV libidn/1.18 libssh2/1.2.8_DEV 
librtmp/2.2e
> Host: apt-test.aviatis.com
> Accept: */*
>
* SSLv3, TLS handshake, Hello request (0):
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* SSL read: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake 
failure, errno 0
* Closing connection #0
curl: (56) SSL read: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert 
handshake failure, errno 0


... to me, it seems the remote server is a bit troublesome.


-- 

 / daniel.haxx.se




Information forwarded to debian-bugs-dist@lists.debian.org, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>:
Bug#594150; Package libcurl3-gnutls. (Sun, 14 Nov 2010 15:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon McVittie <smcv@debian.org>:
Extra info received and forwarded to list. Copy sent to Ramakrishnan Muthukrishnan <rkrishnan@debian.org>. (Sun, 14 Nov 2010 15:21:03 GMT) Full text and rfc822 format available.

Message #49 received at 594150@bugs.debian.org (full text, mbox):

From: Simon McVittie <smcv@debian.org>
To: Daniel Stenberg <daniel@haxx.se>
Cc: "Steve M. Robbins" <steve@sumost.ca>, 594150@bugs.debian.org, Johannes Ernst <johannes.ernst@gmail.com>, David Kalnischkies <kalnischkies+debian@gmail.com>, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>
Subject: Re: Bug#594153: Bug#594150: CURLOPT_TIMEOUT defaults to zero seconds
Date: Sun, 14 Nov 2010 15:17:16 +0000
On Sun, 14 Nov 2010 at 12:51:34 +0100, Daniel Stenberg wrote:
> This turned out to be a minor bug in curl, yes, and I've fixed it
> upstream now.

Thanks!

(https://github.com/bagder/curl/commit/cbf4961bf3e42d88f6489f981efd509faa86f501
for those following the Debian bug log)

> BUT, I'd like to stress that the timeout problem was
> just a false track and it simply made the error reporting a bit
> confused and now with my fix curl will instead say this:
> 
> $ ./src/curl -k https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/
> -v

That's not meant to work here: the test case is an apt repository where you
have to present a client certificate to gain access. Presumably Johannes also
has a real repository that contains private data or something, but this one is
just a mirror of ftp.us.debian.org configured with similar access control, for
testing; see http://apt-test.aviatis.com/ for a working client certificate and
its private key.

> curl: (35) gnutls_handshake() failed: Decryption has failed.

> routines:SSL3_READ_BYTES:sslv3 alert handshake failure, errno 0

You'd know better than I do whether these are what you'd expect to see if the
server requires a client certificate and you didn't have one...

I'm not sure whether apt-cacher does directory listings, but here's the
URL to a flat-file which works with Debian's (OpenSSL-based) curl(1):

https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/Release

The command I've been using to test is something like this:

curl -k https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/Release --cert ../test-client.apt-test.aviatis.com.crt --key ../test-client.apt-test.aviatis.com.key

Hope this helps,
    S




Information forwarded to debian-bugs-dist@lists.debian.org, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>:
Bug#594150; Package libcurl3-gnutls. (Sun, 14 Nov 2010 17:09:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Ramakrishnan Muthukrishnan <rkrishnan@debian.org>. (Sun, 14 Nov 2010 17:09:05 GMT) Full text and rfc822 format available.

Message #54 received at 594150@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: 594150-submitter@bugs.debian.org
Cc: 594150@bugs.debian.org
Subject: More information
Date: Sun, 14 Nov 2010 17:07:24 +0000
[Message part 1 (text/plain, inline)]
Daniel Silverstone & I have been trying to get some debug output of
this bug during the Manchester BSP. 

It strongly appears to be a bug in the gnutls library, rather than curl
and is also restricted to client certificates only. gnutls is failing
in the rehandshake for client certificates. This section of gtls.c:

  if(ret == GNUTLS_E_REHANDSHAKE) {
    /* BLOCKING call, this is bad but a work-around for now. Fixing
this "the proper way" takes a whole lot of work. */
    CURLcode rc = handshake(conn, num, FALSE, FALSE);
    if(rc)
      /* handshake() writes error message on its own */
      *curlcode = rc;
    else
      *curlcode = CURLE_AGAIN; /* then return as if this was a
wouldblock */ return -1;
  }

Performing a manual glutls-cli does not work for client certificates
when the equivalent command with openssl s_client does work.

Tested with:

gnutls-cli --insecure -p 443
--x509certfile /etc/apt/client-certs/test-client.apt-test.aviatis.com.crt
--x509keyfile /etc/apt/client-certs/test-client.apt-test.aviatis.com.key
apt-test.aviatis.com

Also tested with libgnutls26 (2.10.2-1) from experimental.

Entering the data:
GET /apt-cacher/ftp.us.debian.org/debian/dists/squeeze/Release HTTP/1.1
Host: apt-test.aviatis.com

Gives:

*** Non fatal error: Rehandshake was requested by the peer.
*** Received rehandshake request

*** Fatal error: Unsafe renegotiation denied.
*** Rehandshake Failed.
*** Fatal error: An unexpected TLS packet was received.
*** Server has terminated the connection abnormally.

openssl command:
openssl s_client -key test-client.apt-test.aviatis.com.key -cert
test-client.apt-test.aviatis.com.crt -connect apt-test.aviatis.com:https

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]

Message sent on to Johannes Ernst <johannes.ernst@gmail.com>:
Bug#594150. (Sun, 14 Nov 2010 17:09:09 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>:
Bug#594150; Package libcurl3-gnutls. (Sun, 14 Nov 2010 22:15:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Steve M. Robbins" <steve@sumost.ca>:
Extra info received and forwarded to list. Copy sent to Ramakrishnan Muthukrishnan <rkrishnan@debian.org>. (Sun, 14 Nov 2010 22:15:06 GMT) Full text and rfc822 format available.

Message #62 received at 594150@bugs.debian.org (full text, mbox):

From: "Steve M. Robbins" <steve@sumost.ca>
To: Simon McVittie <smcv@debian.org>
Cc: Daniel Stenberg <daniel@haxx.se>, 594150@bugs.debian.org, Johannes Ernst <johannes.ernst@gmail.com>, David Kalnischkies <kalnischkies+debian@gmail.com>, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>
Subject: Re: Bug#594153: Bug#594150: CURLOPT_TIMEOUT defaults to zero seconds
Date: Sun, 14 Nov 2010 16:11:11 -0600
[Message part 1 (text/plain, inline)]
On Sun, Nov 14, 2010 at 03:17:16PM +0000, Simon McVittie wrote:
> On Sun, 14 Nov 2010 at 12:51:34 +0100, Daniel Stenberg wrote:
> > This turned out to be a minor bug in curl, yes, and I've fixed it
> > upstream now.
> 
> Thanks!
> 
> (https://github.com/bagder/curl/commit/cbf4961bf3e42d88f6489f981efd509faa86f501
> for those following the Debian bug log)

Wow, thanks a heap to Daniel and Simon for investigating this issue
because it's been way over my head :-)

My interest is in reducing the RC bug count to get squeeze released.
So let me ask the questions: 

1. There was a minor bug in curl now fixed upstream and in github; is
   there really an RC bug here?  
2. If so, is it in curl or in apt-transport-https?

Cheers,
-Steve

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>:
Bug#594150; Package libcurl3-gnutls. (Sun, 21 Nov 2010 23:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon McVittie <smcv@debian.org>:
Extra info received and forwarded to list. Copy sent to Ramakrishnan Muthukrishnan <rkrishnan@debian.org>. (Sun, 21 Nov 2010 23:33:03 GMT) Full text and rfc822 format available.

Message #67 received at 594150@bugs.debian.org (full text, mbox):

From: Simon McVittie <smcv@debian.org>
To: "Steve M. Robbins" <steve@sumost.ca>, 594150@bugs.debian.org
Cc: Neil Williams <codehelp@debian.org>, Johannes Ernst <johannes.ernst@gmail.com>, David Kalnischkies <kalnischkies+debian@gmail.com>
Subject: Re: Bug#594150: regression in apt-transport-https interop with apt-cacher
Date: Sun, 21 Nov 2010 23:31:22 +0000
retitle 594150 regression in apt-transport-https interop with apt-cacher
reassign 594150 gnutls26
thanks

> My interest is in reducing the RC bug count to get squeeze released.
> So let me ask the questions: 
> 
> 1. There was a minor bug in curl now fixed upstream and in github; is
>    there really an RC bug here?  
> 2. If so, is it in curl or in apt-transport-https?

Johannes' original bug report was (paraphrasing): a-t-h in Lenny worked with a
particular apt-cacher configuration; a-t-h in Squeeze does not. Johannes
believes this to have grave severity and nobody has contradicted that.

According to Neil Williams and Daniel Silverstone (see
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594150#54>), the bug is
probably in gnutls26, if anything; the curl bug that Daniel Stenberg recently
fixed was just obscuring the cause of failure, by causing a misleading error
message.

I've moved the curl upstream and Debian maintainers to Bcc so they'll get this
message but not its replies, since this doesn't seem to be a curl issue. Thanks
for your help!

On Sun, 14 Nov 2010 at 17:07:24 +0000, Neil Williams wrote:
> gnutls-cli --insecure -p 443
> --x509certfile /etc/apt/client-certs/test-client.apt-test.aviatis.com.crt
> --x509keyfile /etc/apt/client-certs/test-client.apt-test.aviatis.com.key
> apt-test.aviatis.com
[...]
> *** Non fatal error: Rehandshake was requested by the peer.
> *** Received rehandshake request
> *** Fatal error: Unsafe renegotiation denied.
> *** Rehandshake Failed.

That sounds to me as though it might be fallout from CVE-2009-3555. I've
reassigned this to gnutls in the hope that one of its maintainers can shed
some light on it - if this isn't gnutls' fault, please reassign or close
as appropriate.

Johannes, how exactly are you running apt-cacher? Is it running as a CGI
or a standalone server or what? Could you publish the configuration of your
(very useful) test server somewhere?

In particular, if Apache is involved in serving the cache, where do the
SSLVerifyClient and SSLCipherSuite directives appear in your server's
configuration, and is it as recommended in
<http://www.debian.org/security/2009/dsa-1934>?

Thanks,
    Simon




Changed Bug title to 'regression in apt-transport-https interop with apt-cacher' from 'CURLOPT_TIMEOUT defaults to zero seconds' Request was from Simon McVittie <smcv@debian.org> to control@bugs.debian.org. (Tue, 23 Nov 2010 01:09:11 GMT) Full text and rfc822 format available.

Bug reassigned from package 'libcurl3-gnutls' to 'gnutls26'. Request was from Simon McVittie <smcv@debian.org> to control@bugs.debian.org. (Tue, 23 Nov 2010 01:09:13 GMT) Full text and rfc822 format available.

Bug No longer marked as found in versions curl/7.21.0-1 and curl/7.21.1-1. Request was from Simon McVittie <smcv@debian.org> to control@bugs.debian.org. (Tue, 23 Nov 2010 01:09:14 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#594150; Package gnutls26. (Tue, 23 Nov 2010 19:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Tue, 23 Nov 2010 19:24:03 GMT) Full text and rfc822 format available.

Message #78 received at 594150@bugs.debian.org (full text, mbox):

From: Andreas Metzler <ametzler@downhill.at.eu.org>
To: Simon McVittie <smcv@debian.org>, 594150@bugs.debian.org
Cc: "Steve M. Robbins" <steve@sumost.ca>, Neil Williams <codehelp@debian.org>, Johannes Ernst <johannes.ernst@gmail.com>, David Kalnischkies <kalnischkies+debian@gmail.com>
Subject: Re: Bug#594150: regression in apt-transport-https interop with apt-cacher
Date: Tue, 23 Nov 2010 20:21:37 +0100
On 2010-11-22 Simon McVittie <smcv@debian.org> wrote:
[...]
> On Sun, 14 Nov 2010 at 17:07:24 +0000, Neil Williams wrote:
> > gnutls-cli --insecure -p 443
> > --x509certfile /etc/apt/client-certs/test-client.apt-test.aviatis.com.crt
> > --x509keyfile /etc/apt/client-certs/test-client.apt-test.aviatis.com.key
> > apt-test.aviatis.com
> [...]
> > *** Non fatal error: Rehandshake was requested by the peer.
> > *** Received rehandshake request
> > *** Fatal error: Unsafe renegotiation denied.
> > *** Rehandshake Failed.

> That sounds to me as though it might be fallout from CVE-2009-3555. I've
> reassigned this to gnutls in the hope that one of its maintainers can shed
> some light on it - if this isn't gnutls' fault, please reassign or close
> as appropriate.

As a suporting data point: 
gnutls-cli --priority NORMAL:%UNSAFE_RENEGOTIATION 
succeeds.

I will ask gnutls upstream to make sure.

cu andreas




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#594150; Package gnutls26. (Tue, 23 Nov 2010 19:54:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Johannes Ernst <johannes.ernst@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Tue, 23 Nov 2010 19:54:07 GMT) Full text and rfc822 format available.

Message #83 received at 594150@bugs.debian.org (full text, mbox):

From: Johannes Ernst <johannes.ernst@gmail.com>
To: Simon McVittie <smcv@debian.org>
Cc: "Steve M. Robbins" <steve@sumost.ca>, 594150@bugs.debian.org, Neil Williams <codehelp@debian.org>, David Kalnischkies <kalnischkies+debian@gmail.com>
Subject: Re: Bug#594150: regression in apt-transport-https interop with apt-cacher
Date: Tue, 23 Nov 2010 11:50:42 -0800
Apologies that I didn't see this question earlier:

http://apt-test.aviatis.com/ has now been updated with the Apache configuration.


On Nov 21, 2010, at 15:31, Simon McVittie wrote:

> Johannes, how exactly are you running apt-cacher? Is it running as a CGI
> or a standalone server or what? Could you publish the configuration of your
> (very useful) test server somewhere?
> 
> In particular, if Apache is involved in serving the cache, where do the
> SSLVerifyClient and SSLCipherSuite directives appear in your server's
> configuration, and is it as recommended in
> <http://www.debian.org/security/2009/dsa-1934>?
> 
> Thanks,
>    Simon





Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#594150; Package gnutls26. (Wed, 24 Nov 2010 15:39:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon McVittie <smcv@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 24 Nov 2010 15:39:07 GMT) Full text and rfc822 format available.

Message #88 received at 594150@bugs.debian.org (full text, mbox):

From: Simon McVittie <smcv@debian.org>
To: Johannes Ernst <johannes.ernst@gmail.com>, 594150@bugs.debian.org
Cc: "Steve M. Robbins" <steve@sumost.ca>, Neil Williams <codehelp@debian.org>, David Kalnischkies <kalnischkies+debian@gmail.com>
Subject: Re: Bug#594150: regression in apt-transport-https interop with apt-cacher
Date: Wed, 24 Nov 2010 15:37:17 +0000
On Tue, 23 Nov 2010 at 11:50:42 -0800, Johannes Ernst wrote:
> Apologies that I didn't see this question earlier:
> 
> http://apt-test.aviatis.com/ has now been updated with the Apache configuration.

Thank you! I think this is indeed fallout from CVE-2009-3555 (DSA-1394).
Quoting from the DSA, http://www.debian.org/security/2009/dsa-1934:

    A design flaw has been found in the TLS and SSL protocol that allows
    an attacker to inject arbitrary content at the beginning of a TLS/SSL
    connection. The attack is related to the way how TLS and SSL handle
    session renegotiations [...]  The attack is still possible in
    configurations where the server initiates the renegotiation. This
    is the case for the following configurations (the information in
    the changelog of the updated packages is slightly inaccurate):

        * The "SSLVerifyClient" directive is used in a Directory or
          Location context.
	* The "SSLCipherSuite" directive is used in
          a Directory or Location context.

Your server has SSLVerifyClient in a Directory context (really DirectoryMatch,
but that's equivalent), so when the client announces its intention to access
a path below /apt-cacher, your server performs renegotiation.

The TLS client used by apt-transport-https (gnutls) notices that this
renegotiation could be someone exploiting CVE-2009-3555, so it aborts the
TLS handshake.

The workaround suggested by DSA-1394 would be to move SSLVerifyClient up to
the <VirtualHost> context, avoiding the need for renegotiation (doing that
will require client certificates for the entire server, not just the
/apt-cacher path, though). Could you try that on your server? If that works,
I think we can close this bug.

The real fix for your configuration requires the server's apache2 and openssl
to be upgraded to versions which can perform secure renegotiation as an
extension; in squeeze that's been fixed in openssl >= 0.9.8m-1 and
apache2 >= 2.2.15-1, but these changes haven't been backported to lenny.

Regards,
    Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#594150; Package gnutls26. (Wed, 24 Nov 2010 15:57:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Johannes Ernst <johannes.ernst@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 24 Nov 2010 15:57:06 GMT) Full text and rfc822 format available.

Message #93 received at 594150@bugs.debian.org (full text, mbox):

From: Johannes Ernst <johannes.ernst@gmail.com>
To: Simon McVittie <smcv@debian.org>
Cc: 594150@bugs.debian.org, "Steve M. Robbins" <steve@sumost.ca>, Neil Williams <codehelp@debian.org>, David Kalnischkies <kalnischkies+debian@gmail.com>
Subject: Re: Bug#594150: regression in apt-transport-https interop with apt-cacher
Date: Wed, 24 Nov 2010 07:52:49 -0800
Assuming this is the right diagnosis, I still think this is a bug: it can't take several people several months (like us on this thread) to figure out that some setting needs to be moved by two lines. Lots of people will be upgrading their existing, working, Apache settings when migrating to squeeze, and they will expect (like me) that they continue to work, and certainly not silently fail.

At the minimum, can this generate a really nice and big and comprehensible error message?


On Nov 24, 2010, at 7:37, Simon McVittie wrote:

> On Tue, 23 Nov 2010 at 11:50:42 -0800, Johannes Ernst wrote:
>> Apologies that I didn't see this question earlier:
>> 
>> http://apt-test.aviatis.com/ has now been updated with the Apache configuration.
> 
> Thank you! I think this is indeed fallout from CVE-2009-3555 (DSA-1394).
> Quoting from the DSA, http://www.debian.org/security/2009/dsa-1934:
> 
>    A design flaw has been found in the TLS and SSL protocol that allows
>    an attacker to inject arbitrary content at the beginning of a TLS/SSL
>    connection. The attack is related to the way how TLS and SSL handle
>    session renegotiations [...]  The attack is still possible in
>    configurations where the server initiates the renegotiation. This
>    is the case for the following configurations (the information in
>    the changelog of the updated packages is slightly inaccurate):
> 
>        * The "SSLVerifyClient" directive is used in a Directory or
>          Location context.
> 	* The "SSLCipherSuite" directive is used in
>          a Directory or Location context.
> 
> Your server has SSLVerifyClient in a Directory context (really DirectoryMatch,
> but that's equivalent), so when the client announces its intention to access
> a path below /apt-cacher, your server performs renegotiation.
> 
> The TLS client used by apt-transport-https (gnutls) notices that this
> renegotiation could be someone exploiting CVE-2009-3555, so it aborts the
> TLS handshake.
> 
> The workaround suggested by DSA-1394 would be to move SSLVerifyClient up to
> the <VirtualHost> context, avoiding the need for renegotiation (doing that
> will require client certificates for the entire server, not just the
> /apt-cacher path, though). Could you try that on your server? If that works,
> I think we can close this bug.
> 
> The real fix for your configuration requires the server's apache2 and openssl
> to be upgraded to versions which can perform secure renegotiation as an
> extension; in squeeze that's been fixed in openssl >= 0.9.8m-1 and
> apache2 >= 2.2.15-1, but these changes haven't been backported to lenny.
> 
> Regards,
>    Simon





Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#594150; Package gnutls26. (Wed, 24 Nov 2010 16:45:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon McVittie <smcv@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 24 Nov 2010 16:45:06 GMT) Full text and rfc822 format available.

Message #98 received at 594150@bugs.debian.org (full text, mbox):

From: Simon McVittie <smcv@debian.org>
To: Johannes Ernst <johannes.ernst@gmail.com>
Cc: 594150@bugs.debian.org, "Steve M. Robbins" <steve@sumost.ca>, Neil Williams <codehelp@debian.org>, David Kalnischkies <kalnischkies+debian@gmail.com>
Subject: Re: Bug#594150: regression in apt-transport-https interop with apt-cacher
Date: Wed, 24 Nov 2010 16:42:51 +0000
On Wed, 24 Nov 2010 at 07:52:49 -0800, Johannes Ernst wrote:
> Assuming this is the right diagnosis, I still think this is a bug:
> it can't take several people several months (like us on this thread)
> to figure out that some setting needs to be moved by two lines. Lots of
> people will be upgrading their existing, working, Apache settings when
> migrating to squeeze, and they will expect (like me) that they continue
> to work, and certainly not silently fail.

Do I understand correctly that your clients use squeeze's apt-transport-https,
libcurl and gnutls, while your server uses lenny's apache2, openssl and
apt-cacher?

If I've understood this correctly, the underlying bug is at the server side:
lenny's apache2 and openssl can't perform secure renegotiation. If so,
this isn't a regression in squeeze on your clients, so much as an
unfixed/hard-to-fix bug in lenny on your server (that's made visible by using
the newer clients).

I believe you need to apply the workaround suggested by DSA-1394 if you're
staying with lenny versions on the server; however, if you upgrade your server
to squeeze versions of apache2 and openssl, your current configuration should
work again.

The "regression" in squeeze is that (the libraries used by)
apt-transport-https will refuse to go ahead with a TLS connection that
might have been hijacked using the vulnerability described in CVE-2009-3555;
this is unavoidable if you want a secure connection, unfortunately.

Relatedly, there's a bug in curl causing it to give a misleading error
message, which made the underlying problem harder to find; this has since
been fixed upstream, and if you/the curl maintainer consider *that* to be
release-critical, we can try to get it fixed in squeeze. If this is what's
left of this bug, we can reassign it back to curl.

Regards,
    Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#594150; Package gnutls26. (Wed, 24 Nov 2010 18:27:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Johannes Ernst <johannes.ernst@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 24 Nov 2010 18:27:05 GMT) Full text and rfc822 format available.

Message #103 received at 594150@bugs.debian.org (full text, mbox):

From: Johannes Ernst <johannes.ernst@gmail.com>
To: Simon McVittie <smcv@debian.org>
Cc: 594150@bugs.debian.org, "Steve M. Robbins" <steve@sumost.ca>, Neil Williams <codehelp@debian.org>, David Kalnischkies <kalnischkies+debian@gmail.com>
Subject: Re: Bug#594150: regression in apt-transport-https interop with apt-cacher
Date: Wed, 24 Nov 2010 10:24:51 -0800
On Nov 24, 2010, at 8:42, Simon McVittie wrote:

> On Wed, 24 Nov 2010 at 07:52:49 -0800, Johannes Ernst wrote:
>> Assuming this is the right diagnosis, I still think this is a bug:
>> it can't take several people several months (like us on this thread)
>> to figure out that some setting needs to be moved by two lines. Lots of
>> people will be upgrading their existing, working, Apache settings when
>> migrating to squeeze, and they will expect (like me) that they continue
>> to work, and certainly not silently fail.
> 
> Do I understand correctly that your clients use squeeze's apt-transport-https,
> libcurl and gnutls, while your server uses lenny's apache2, openssl and
> apt-cacher?

Yes.

> If I've understood this correctly, the underlying bug is at the server side:
> lenny's apache2 and openssl can't perform secure renegotiation. If so,
> this isn't a regression in squeeze on your clients, so much as an
> unfixed/hard-to-fix bug in lenny on your server (that's made visible by using
> the newer clients).

Fair enough.

> I believe you need to apply the workaround suggested by DSA-1394 if you're
> staying with lenny versions on the server; however, if you upgrade your server
> to squeeze versions of apache2 and openssl, your current configuration should
> work again.
> 
> The "regression" in squeeze is that (the libraries used by)
> apt-transport-https will refuse to go ahead with a TLS connection that
> might have been hijacked using the vulnerability described in CVE-2009-3555;
> this is unavoidable if you want a secure connection, unfortunately.
> 
> Relatedly, there's a bug in curl causing it to give a misleading error
> message, which made the underlying problem harder to find; this has since
> been fixed upstream, and if you/the curl maintainer consider *that* to be
> release-critical, we can try to get it fixed in squeeze. If this is what's
> left of this bug, we can reassign it back to curl.

Personally I think this is critical. Both curl and apt-transport-https should emit an error message that explains what's going on so mere mortals have a way of understanding it.

> 
> Regards,
>    Simon





Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#594150; Package gnutls26. (Wed, 24 Nov 2010 18:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon McVittie <smcv@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 24 Nov 2010 18:42:03 GMT) Full text and rfc822 format available.

Message #108 received at 594150@bugs.debian.org (full text, mbox):

From: Simon McVittie <smcv@debian.org>
To: Johannes Ernst <johannes.ernst@gmail.com>
Cc: 594150@bugs.debian.org, "Steve M. Robbins" <steve@sumost.ca>, Neil Williams <codehelp@debian.org>, David Kalnischkies <kalnischkies+debian@gmail.com>
Subject: Re: Bug#594150: regression in apt-transport-https interop with apt-cacher
Date: Wed, 24 Nov 2010 18:39:12 +0000
retitle 594150 "no useful error message if server attempts insecure renegotiation"
reassign 594150 libcurl3-gnutls 7.21.0-1
found 594150 7.21.1-1
thanks

On Wed, 24 Nov 2010 at 10:24:51 -0800, Johannes Ernst wrote:
> On Nov 24, 2010, at 8:42, Simon McVittie wrote:
> > The "regression" in squeeze is that (the libraries used by)
> > apt-transport-https will refuse to go ahead with a TLS connection that
> > might have been hijacked using the vulnerability described in CVE-2009-3555;
> > this is unavoidable if you want a secure connection, unfortunately.
> > 
> > Relatedly, there's a bug in curl causing it to give a misleading error
> > message, which made the underlying problem harder to find; this has since
> > been fixed upstream, and if you/the curl maintainer consider *that* to be
> > release-critical, we can try to get it fixed in squeeze. If this is what's
> > left of this bug, we can reassign it back to curl.
> 
> Personally I think this is critical. Both curl and apt-transport-https should emit an error message that explains what's going on so mere mortals have a way of understanding it.

Fair enough, back to libcurl-gnutls it goes... hopefully Daniel Stenberg's
patch from several messages ago is enough to produce sensible output.

Regards,
    Simon




Changed Bug title to '"no useful error message if server attempts insecure renegotiation"' from 'regression in apt-transport-https interop with apt-cacher' Request was from Simon McVittie <smcv@debian.org> to control@bugs.debian.org. (Wed, 24 Nov 2010 18:42:06 GMT) Full text and rfc822 format available.

Bug reassigned from package 'gnutls26' to 'libcurl3-gnutls'. Request was from Simon McVittie <smcv@debian.org> to control@bugs.debian.org. (Wed, 24 Nov 2010 18:42:07 GMT) Full text and rfc822 format available.

Bug Marked as found in versions curl/7.21.0-1. Request was from Simon McVittie <smcv@debian.org> to control@bugs.debian.org. (Wed, 24 Nov 2010 18:42:08 GMT) Full text and rfc822 format available.

Bug Marked as found in versions curl/7.21.1-1. Request was from Simon McVittie <smcv@debian.org> to control@bugs.debian.org. (Wed, 24 Nov 2010 18:42:10 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>:
Bug#594150; Package libcurl3-gnutls. (Fri, 17 Dec 2010 21:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Ramakrishnan Muthukrishnan <rkrishnan@debian.org>. (Fri, 17 Dec 2010 21:33:03 GMT) Full text and rfc822 format available.

Message #121 received at 594150@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: 594150@bugs.debian.org, 594150-submitter@bugs.debian.org, Simon McVittie <smcv@debian.org>, Daniel Silverstone <dsilvers@debian.org>
Cc: debian-release@lists.debian.org
Subject: Possible curl t-p-u ?
Date: Fri, 17 Dec 2010 21:29:40 +0000
[Message part 1 (text/plain, inline)]
I've tidied up the patch which turns this silent error into a more
noisy warning but does not try to fix the underlying issue. The patch
is based on one by Johannes Ernst <johannes.ernst@gmail.com>, as
detailed in the attached patch. (The only other change is to put the
patch into the series file *in the middle* due to problems with the
gnutls changes needing to be last.)

#libtool
no_com_err
runtests_gdb
art_http_scripting
versioned
insecure-negotiation-warning

# this must be the last
curl_links_with_rt
gnutls

curl has already had a new upstream release uploaded, so I'm
building against testing (pbuilder):

Source: curl
Version: 7.21.0-1.1
Distribution: testing-proposed-updates
Urgency: medium
Maintainer: Neil Williams <codehelp@debian.org>
Date: Fri, 17 Dec 2010 21:10:56 +0000
Closes: 594150
Changes: 
 curl (7.21.0-1.1) testing-proposed-updates; urgency=medium
 .
   * Non-maintainer upload.
   * Backport change by Johannes Ernst to Squeeze to supply
     a useful error message if server attempts insecure
     renegotiation. (Closes: #594150)
   * Target t-p-u because a new upstream release is in sid.

If the patch works as expected (and the build passes the tests which
have proved problematic on this box previously), would a t-p-u upload
like this be a suitable fix for the release?

I'm guessing medium here, quite happy to change that to suit release
team preference.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

[insecure-negotiation-warning (application/octet-stream, attachment)]
[Message part 3 (application/pgp-signature, inline)]

Message sent on to Johannes Ernst <johannes.ernst@gmail.com>:
Bug#594150. (Fri, 17 Dec 2010 21:33:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>:
Bug#594150; Package libcurl3-gnutls. (Fri, 17 Dec 2010 23:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Ramakrishnan Muthukrishnan <rkrishnan@debian.org>. (Fri, 17 Dec 2010 23:03:03 GMT) Full text and rfc822 format available.

Message #129 received at 594150@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: 594150@bugs.debian.org, 594150-submitter@bugs.debian.org, Simon McVittie <smcv@debian.org>, Daniel Silverstone <dsilvers@debian.org>
Cc: debian-release@lists.debian.org
Subject: test results
Date: Fri, 17 Dec 2010 22:59:17 +0000
[Message part 1 (text/plain, inline)]
Testing in a Squeeze pbuilder login with unchanged packages:
Downloaded from http://apt-test.aviatis.com/

root@dwarf:~# ls /etc/apt/client-certs/
client.apt-test.aviatis.com.crt  client.apt-test.aviatis.com.key

root@dwarf:~# cat /etc/apt/sources.list
deb http://ftp.uk.debian.org/debian/ testing main
deb-src http://ftp.uk.debian.org/debian/ testing main
deb https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/
squeeze main

root@dwarf:~# cat /etc/apt/apt.conf.d/client-cert 
Acquire {
  https {
        Verify-Peer "false";
        CaPath  "/etc/ssl/certs";
        Verify-Host "false";
        AllowRedirect  "true";

        SslCert "/etc/apt/client-certs/client.apt-test.aviatis.com.crt";
        SslKey  "/etc/apt/client-certs/client.apt-test.aviatis.com.key";
        SslForceVersion "SSLv3"; // This is required to get it to work in lenny; not sure why.
   }
}

(Note the revealing comment about the ForceVersion - this turns out to be important.)

Tested using:
apt-transport-https       0.8.8

root@dwarf:~# apt-get update
Hit http://ftp.uk.debian.org testing Release.gpg
Ign http://ftp.uk.debian.org/debian/ testing/main Translation-en
Hit http://ftp.uk.debian.org testing Release
Hit http://ftp.uk.debian.org testing/main Sources/DiffIndex
Hit http://ftp.uk.debian.org testing/main amd64 Packages/DiffIndex
Ign https://apt-test.aviatis.com squeeze Release.gpg
Ign https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/
squeeze/main Translation-en Ign https://apt-test.aviatis.com squeeze
Release Ign https://apt-test.aviatis.com squeeze/main amd64 Packages
Err https://apt-test.aviatis.com squeeze/main amd64 Packages
  SSL connection timeout
W: Failed to fetch
https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/main/binary-amd64/Packages.gz
SSL connection timeout

E: Some index files failed to download, they have been ignored, or old
ones used instead.

Install the patched update NMU packages:

root@dwarf:~# dpkg -i ../curl_7.21.0-1.1_amd64.deb ../libcurl3_7.21.0-1.1_amd64.deb ../libcurl3-gnutls_7.21.0-1.1_amd64.deb 
(Reading database ... 12732 files and directories currently installed.)
Preparing to replace curl 7.21.0-1 (using ../curl_7.21.0-1.1_amd64.deb) ...
Unpacking replacement curl ...
Preparing to replace libcurl3 7.21.0-1 (using .../libcurl3_7.21.0-1.1_amd64.deb) ...
Unpacking replacement libcurl3 ...
Preparing to replace libcurl3-gnutls 7.21.0-1 (using .../libcurl3-gnutls_7.21.0-1.1_amd64.deb) ...
Unpacking replacement libcurl3-gnutls ...
Setting up libcurl3 (7.21.0-1.1) ...
Setting up libcurl3-gnutls (7.21.0-1.1) ...
Setting up curl (7.21.0-1.1) ...

test:

root@dwarf:~# apt-get update
Hit http://ftp.uk.debian.org testing Release.gpg
Ign http://ftp.uk.debian.org/debian/ testing/main Translation-en
Hit http://ftp.uk.debian.org testing Release
Hit http://ftp.uk.debian.org testing/main Sources/DiffIndex
Hit http://ftp.uk.debian.org testing/main amd64 Packages/DiffIndex
Get:1 https://apt-test.aviatis.com squeeze Release.gpg [835 B]
Ign https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/ squeeze/main Translation-en
Get:2 https://apt-test.aviatis.com squeeze Release [89.9 kB]
Get:3 https://apt-test.aviatis.com squeeze/main amd64 Packages [6562 kB]
Fetched 6653 kB in 52s (126 kB/s)
Reading package lists... Done

The results with apt-get update are reproducible, yet calls to the
underlying utilities would give the impression that nothing has changed.

e.g.
# gnutls-cli -V --insecure -p 433
--x509certfile /etc/apt/client-certs/client.apt-test.aviatis.com.crt
--x509keyfile /etc/apt/client-certs/client.apt-test.aviatis.com.key
apt-test.aviatis.com
Processed 1 client certificates...
Processed 1 client X.509 certificates...
Resolving 'apt-test.aviatis.com'...
Connecting to '204.145.147.227:433'...
Cannot connect to apt-test.aviatis.com:433: Connection timed out

No change with the patched package.

whilst curl works fine (with and without the change)
curl -v  -k https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/Release --cert /etc/apt/client-certs/client.apt-test.aviatis.com.crt --key /etc/apt/client-certs/client.apt-test.aviatis.com.key 

Then with a sid pbuilder login without any patches:
ii  apt-transport-https       0.8.10

root@dwarf:/etc/apt/client-certs# apt-get update
Hit http://ftp.fr.debian.org sid Release.gpg
Ign http://ftp.fr.debian.org/debian/ sid/main Translation-en
Hit http://ftp.fr.debian.org sid Release
Hit http://ftp.fr.debian.org sid/main Sources/DiffIndex
Hit http://ftp.fr.debian.org sid/main amd64 Packages/DiffIndex
Ign https://apt-test.aviatis.com squeeze Release.gpg
Ign https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/ squeeze/main Translation-en
Ign https://apt-test.aviatis.com squeeze Release
Ign https://apt-test.aviatis.com squeeze/main amd64 Packages
Err https://apt-test.aviatis.com squeeze/main amd64 Packages
  SSL connection timeout
W: Failed to fetch https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/main/binary-amd64/Packages.gz  SSL connection timeout

E: Some index files failed to download, they have been ignored, or old ones used instead.

Same results for the curl and gnutls test commands as in Squeeze (patched or not).

More light is shed when the /etc/apt/apt.conf.d/client-cert is edited
to remove the line forcing SSHv3:

With the patched packages installed:

root@dwarf:~# cat /etc/apt/apt.conf.d/client-cert 
Acquire {
  https {
        Verify-Peer "false";
        CaPath  "/etc/ssl/certs";
        Verify-Host "false";
        AllowRedirect  "true";

        SslCert "/etc/apt/client-certs/client.apt-test.aviatis.com.crt";
        SslKey  "/etc/apt/client-certs/client.apt-test.aviatis.com.key";
   }
}

root@dwarf:~# apt-get update
Hit http://ftp.uk.debian.org testing Release.gpg     
Ign http://ftp.uk.debian.org/debian/ testing/main Translation-en
Hit http://ftp.uk.debian.org testing Release
Hit http://ftp.uk.debian.org testing/main Sources/DiffIndex
Ign https://apt-test.aviatis.com squeeze Release.gpg
Hit http://ftp.uk.debian.org testing/main amd64 Packages/DiffIndex
Ign https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/ squeeze/main Translation-en
Ign https://apt-test.aviatis.com squeeze Release
Ign https://apt-test.aviatis.com squeeze/main amd64 Packages/DiffIndex
Ign https://apt-test.aviatis.com squeeze/main amd64 Packages
Err https://apt-test.aviatis.com squeeze/main amd64 Packages
  gnutls_handshake() failed: Decryption has failed.
W: Failed to fetch https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/main/binary-amd64/Packages.gz  gnutls_handshake() failed: Decryption has failed.

E: Some index files failed to download, they have been ignored, or old ones used instead.

handshake blamed with the patch

root@dwarf:~# dpkg -l | grep curl
ii  curl                            7.21.0-1.1                  Get a file from an HTTP, HTTPS or FTP server
ii  libcurl3                        7.21.0-1.1                  Multi-protocol file transfer library (OpenSSL)
ii  libcurl3-gnutls                 7.21.0-1.1                  Multi-protocol file transfer library (GnuTLS)

Downgrading back to Squeeze:
Setting up libcurl3 (7.21.0-1) ...
Setting up curl (7.21.0-1) ...
Setting up libcurl3-gnutls (7.21.0-1) ...

root@dwarf:~# apt-get update
Hit http://ftp.uk.debian.org testing Release.gpg
Ign http://ftp.uk.debian.org/debian/ testing/main Translation-en
Hit http://ftp.uk.debian.org testing Release
Hit http://ftp.uk.debian.org testing/main Sources/DiffIndex
Hit http://ftp.uk.debian.org testing/main amd64 Packages/DiffIndex
Ign https://apt-test.aviatis.com squeeze Release.gpg
Ign https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/ squeeze/main Translation-en
Ign https://apt-test.aviatis.com squeeze Release
Ign https://apt-test.aviatis.com squeeze/main amd64 Packages/DiffIndex
Ign https://apt-test.aviatis.com squeeze/main amd64 Packages
Err https://apt-test.aviatis.com squeeze/main amd64 Packages
  SSL connection timeout
W: Failed to fetch https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/main/binary-amd64/Packages.gz
  SSL connection timeout

E: Some index files failed to download, they have been ignored, or old ones used instead.

timeout blamed without the patch.

So the patch certainly has the effect of making the test apt source
usable under the original test conditions and it remains unusable
without the patch or with packages from unstable but it leaves me
uncertain about how much of this is down to the specific configuration
of these test conditions. (All testing of this bug has involved this
one test configuration.)

It works but I'd be happier if someone could explain what is actually
happening and why....

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]

Message sent on to Johannes Ernst <johannes.ernst@gmail.com>:
Bug#594150. (Fri, 17 Dec 2010 23:03:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>:
Bug#594150; Package libcurl3-gnutls. (Mon, 20 Dec 2010 20:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Adam D. Barratt" <adam@adam-barratt.org.uk>:
Extra info received and forwarded to list. Copy sent to Ramakrishnan Muthukrishnan <rkrishnan@debian.org>. (Mon, 20 Dec 2010 20:09:03 GMT) Full text and rfc822 format available.

Message #137 received at 594150@bugs.debian.org (full text, mbox):

From: "Adam D. Barratt" <adam@adam-barratt.org.uk>
To: Neil Williams <codehelp@debian.org>
Cc: 594150@bugs.debian.org, 594150-submitter@bugs.debian.org, Simon McVittie <smcv@debian.org>, Daniel Silverstone <dsilvers@debian.org>, debian-release@lists.debian.org
Subject: Re: Possible curl t-p-u ?
Date: Mon, 20 Dec 2010 19:44:47 +0000
On Fri, 2010-12-17 at 21:29 +0000, Neil Williams wrote:
> I've tidied up the patch which turns this silent error into a more
> noisy warning but does not try to fix the underlying issue. The patch
> is based on one by Johannes Ernst <johannes.ernst@gmail.com>, as
> detailed in the attached patch. (The only other change is to put the
> patch into the series file *in the middle* due to problems with the
> gnutls changes needing to be last.)

From the bug log, it looks like this hasn't been fixed in unstable yet;
is that correct?  I appreciate that the unstable package won't be able
to migrate, but I'd prefer to see this fixed there as well rather than
the patch being dropped straight in to squeeze.

[...]
> Distribution: testing-proposed-updates
> Urgency: medium
[...]
> I'm guessing medium here, quite happy to change that to suit release
> team preference.

fwiw, urgency is irrelevant for t-p-u uploads; the package enters
testing once all builds are available and a team member adds an approval
hint, which is one of the reasons we prefer to avoid t-p-u where
possible.

I might be missing something, but this change looks wrong:

+      nonblocking?0:(int)timeout_ms?1000:timeout_ms);

If timeout_ms is non-zero, a hard-coded value of 1000 will be used;
otherwise timeout_ms will be passed, which seems to be exactly what the
change was trying to avoid?

Regards,

Adam





Message sent on to Johannes Ernst <johannes.ernst@gmail.com>:
Bug#594150. (Mon, 20 Dec 2010 20:09:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>:
Bug#594150; Package libcurl3-gnutls. (Tue, 21 Dec 2010 00:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Ramakrishnan Muthukrishnan <rkrishnan@debian.org>. (Tue, 21 Dec 2010 00:00:03 GMT) Full text and rfc822 format available.

Message #145 received at 594150@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: "Adam D. Barratt" <adam@adam-barratt.org.uk>
Cc: 594150@bugs.debian.org, 594150-submitter@bugs.debian.org, Simon McVittie <smcv@debian.org>, Daniel Silverstone <dsilvers@debian.org>, debian-release@lists.debian.org
Subject: Re: Possible curl t-p-u ?
Date: Mon, 20 Dec 2010 23:57:39 +0000
[Message part 1 (text/plain, inline)]
On Mon, 20 Dec 2010 19:44:47 +0000
"Adam D. Barratt" <adam@adam-barratt.org.uk> wrote:

> On Fri, 2010-12-17 at 21:29 +0000, Neil Williams wrote:
> > I've tidied up the patch which turns this silent error into a more
> > noisy warning but does not try to fix the underlying issue. The
> > patch is based on one by Johannes Ernst <johannes.ernst@gmail.com>,
> > as detailed in the attached patch. (The only other change is to put
> > the patch into the series file *in the middle* due to problems with
> > the gnutls changes needing to be last.)
> 
> From the bug log, it looks like this hasn't been fixed in unstable
> yet; is that correct? 

Yes.

> I appreciate that the unstable package won't
> be able to migrate, but I'd prefer to see this fixed there as well
> rather than the patch being dropped straight in to squeeze.

So two uploads? Or shall I clone this bug and mark the clone as found
in the version in sid and this one not found in sid for the maintainer
to look at the underlying problem not fixed by this patch?

> I might be missing something, but this change looks wrong:
> 
> +      nonblocking?0:(int)timeout_ms?1000:timeout_ms);
> 
> If timeout_ms is non-zero, a hard-coded value of 1000 will be used;
> otherwise timeout_ms will be passed, which seems to be exactly what
> the change was trying to avoid?

You'd think so, so did I. After another run through the tests, it makes
absolutely no difference. Alternative code, expanded for a bit of
clarity:

      int repeat = 0;
      if(!nonblocking) {
        repeat = ((int)timeout_ms) ? timeout_ms : 1000;
      }
      what = Curl_socket_ready(readfd, writefd, repeat);

With this version of the patch, apt-transport-https works just as it
does with the other version of the patch. Furthermore the change to the
client-cert described in my previous message (commenting out the force
for SSHv3) produces the same handshake error message with the patch and
the timeout message without it.

I'm still dubious about this whole bug/patch - especially that this
entire process has been only tested against a single setup, the bug
only shows up in a single frontend and the bug has not had any input
from the maintainer who has been otherwise active with uploads and
fixes.

This would appear to be a minor bug in curl [0] which either of
these patches does not fix (merely makes more noisy) and the issue
itself only affects apt-transport-https if a particular client setup is
deployed and the example config easily hides the real issue by
retaining a force setting inherited from a previous Lenny setup.

 SslForceVersion "SSLv3"; // This is required to get it to work
// in lenny; not sure why.

Overall, maybe the best solution here is to downgrade this bug rather
than potentially confuse things further with a patch which itself
doesn't provide a clear fix for the original problem and may be based
on a poorly understood test case.

I'd like some feedback from others involved in this bug and from the RT
before downgrading. Alternatively, some kind of indication that there is
more than just one https server/cert/config combination affected by the
top-level apt-transport-https issue.

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594150#44

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]

Message sent on to Johannes Ernst <johannes.ernst@gmail.com>:
Bug#594150. (Tue, 21 Dec 2010 00:00:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#594150; Package libcurl3-gnutls. (Tue, 21 Dec 2010 17:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ramakrishnan Muthukrishnan <rkrishnan@debian.org>:
Extra info received and forwarded to list. (Tue, 21 Dec 2010 17:57:04 GMT) Full text and rfc822 format available.

Message #153 received at 594150@bugs.debian.org (full text, mbox):

From: Ramakrishnan Muthukrishnan <rkrishnan@debian.org>
To: Neil Williams <codehelp@debian.org>, 594150@bugs.debian.org
Cc: "Adam D. Barratt" <adam@adam-barratt.org.uk>, 594150-submitter@bugs.debian.org, Simon McVittie <smcv@debian.org>, Daniel Silverstone <dsilvers@debian.org>, debian-release@lists.debian.org
Subject: Re: Bug#594150: Possible curl t-p-u ?
Date: Tue, 21 Dec 2010 23:25:47 +0530
On Tue, Dec 21, 2010 at 5:27 AM, Neil Williams <codehelp@debian.org> wrote:
>
> I'm still dubious about this whole bug/patch - especially that this
> entire process has been only tested against a single setup, the bug
> only shows up in a single frontend and the bug has not had any input
> from the maintainer who has been otherwise active with uploads and
> fixes.

Hi,

I didn't respond to this bug because I don't really know curl or apt
internals enough to respond to it. I generally either raise such
things to upstream. Daniel  Stenberg (the curl upstream author) had
been very kind enough to respond directly to many such bug reports.

On this particular issue, I leave it to those of you who know apt and
curl internals better than me. I guess Daniel Stenberg may be the
right person to comment on this problem and comment on your patch.

Thanks
Ramakrishnan




Message sent on to Johannes Ernst <johannes.ernst@gmail.com>:
Bug#594150. (Tue, 21 Dec 2010 17:57:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Ramakrishnan Muthukrishnan <rkrishnan@debian.org>:
Bug#594150; Package libcurl3-gnutls. (Tue, 21 Dec 2010 19:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Ramakrishnan Muthukrishnan <rkrishnan@debian.org>. (Tue, 21 Dec 2010 19:57:02 GMT) Full text and rfc822 format available.

Message #161 received at 594150@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: Ramakrishnan Muthukrishnan <rkrishnan@debian.org>
Cc: 594150@bugs.debian.org, "Adam D. Barratt" <adam@adam-barratt.org.uk>, 594150-submitter@bugs.debian.org, Simon McVittie <smcv@debian.org>, Daniel Silverstone <dsilvers@debian.org>, debian-release@lists.debian.org, control@bugs.debian.org
Subject: Re: Bug#594150: downgrading on advice from upstream
Date: Tue, 21 Dec 2010 19:57:23 +0000
[Message part 1 (text/plain, inline)]
severity 594150 important
tag 594150 fixed-upstream
thanks

On Tue, 21 Dec 2010 23:25:47 +0530
Ramakrishnan Muthukrishnan <rkrishnan@debian.org> wrote:

> On Tue, Dec 21, 2010 at 5:27 AM, Neil Williams <codehelp@debian.org>
> wrote:
> >
> > I'm still dubious about this whole bug/patch - especially that this
> > entire process has been only tested against a single setup, the bug
> > only shows up in a single frontend and the bug has not had any input
> > from the maintainer who has been otherwise active with uploads and
> > fixes.
> 
> I didn't respond to this bug because I don't really know curl or apt
> internals enough to respond to it. I generally either raise such
> things to upstream. Daniel  Stenberg (the curl upstream author) had
> been very kind enough to respond directly to many such bug reports.

It was Daniel's comments which led me to doubt the fix when the test
results were not clear with regard to apt-transport-https:

Sun, 14 Nov 2010 12:51:34 +0100 (CET)
Daniel Stenberg <daniel@haxx.se> wrote:
> This turned out to be a minor bug in curl, yes, and I've fixed it
> upstream now. BUT, I'd like to stress that the timeout problem was
> just a false track and it simply made the error reporting a bit
> confused and now with my fix curl will instead say this:
> [...]
> curl: (35) gnutls_handshake() failed: Decryption has failed.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594150#44

I do get that result with the test configuration IF the SSHv3 force
option is removed and this minor bug in curl is patched. It does not
mean that this bug is the proper fix for the original bug, AFAICT.

I'm not going to proceed on what upstream deem a false track and which
isn't providing clear information in testing. The patch is the wrong
solution to the original issue filed by Johannes. Somewhere through the
CVE patches which led to the original manifestation (lenny vs squeeze),
apt-transport-https lost the ability to cope with the particular
configuration used by the submitter. *If* there is a real bug in that
situation, IMHO it is not a bug in curl itself.
 
> On this particular issue, I leave it to those of you who know apt and
> curl internals better than me. I guess Daniel Stenberg may be the
> right person to comment on this problem and comment on your patch.

Thanks. I think Daniel's been clear on the problem, so I'm downgrading
this bug, to important initially. Ramakrishnan, feel free to downgrade
further.

Johannes - please investigate the original issue further within your
test setup. That comment about forcing SSHv3 looks like a good place to
start. Unless the original apt-transport-https bug can be reproduced
with another configuration unrelated to the current test site or some
one else is able to provide some more detailed insight into this bug,
I'm going to leave any curl part of this to upstream. 

I'm not going to make any curl upload for this bug. IMHO the bug should
not be reassigned to apt-transport-https unless someone can reproduce
the issue or isolate the actual problem in apt-transport-https.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]

Severity set to 'important' from 'grave' Request was from Neil Williams <codehelp@debian.org> to control@bugs.debian.org. (Tue, 21 Dec 2010 19:57:10 GMT) Full text and rfc822 format available.

Added tag(s) fixed-upstream. Request was from Neil Williams <codehelp@debian.org> to control@bugs.debian.org. (Tue, 21 Dec 2010 19:57:12 GMT) Full text and rfc822 format available.

Message sent on to Johannes Ernst <johannes.ernst@gmail.com>:
Bug#594150. (Tue, 21 Dec 2010 19:57:14 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#594150; Package libcurl3-gnutls. (Wed, 19 Jan 2011 16:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ramakrishnan Muthukrishnan <rkrishnan@debian.org>:
Extra info received and forwarded to list. (Wed, 19 Jan 2011 16:57:03 GMT) Full text and rfc822 format available.

Message #173 received at 594150@bugs.debian.org (full text, mbox):

From: Ramakrishnan Muthukrishnan <rkrishnan@debian.org>
To: Simon McVittie <smcv@debian.org>
Cc: "Steve M. Robbins" <steve@sumost.ca>, 594150@bugs.debian.org, Neil Williams <codehelp@debian.org>, Johannes Ernst <johannes.ernst@gmail.com>, David Kalnischkies <kalnischkies+debian@gmail.com>
Subject: Re: Bug#594150: regression in apt-transport-https interop with apt-cacher
Date: Wed, 19 Jan 2011 22:23:12 +0530
On Mon, Nov 22, 2010 at 5:01 AM, Simon McVittie <smcv@debian.org> wrote:
>
> According to Neil Williams and Daniel Silverstone (see
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594150#54>), the bug is
> probably in gnutls26, if anything; the curl bug that Daniel Stenberg recently
> fixed was just obscuring the cause of failure, by causing a misleading error
> message.
>
> I've moved the curl upstream and Debian maintainers to Bcc so they'll get this
> message but not its replies, since this doesn't seem to be a curl issue. Thanks
> for your help!

FYI, I just uploaded curl 7.21.3 into the unstable which has the
changes done by curl upstream. I have added a comment in the changelog
highlighting the upstream changes and this bug number.

Thanks
Ramakrishnan




Reply sent to Alessandro Ghedini <al3xbio@gmail.com>:
You have taken responsibility. (Thu, 17 Nov 2011 19:39:04 GMT) Full text and rfc822 format available.

Notification sent to Johannes Ernst <johannes.ernst@gmail.com>:
Bug acknowledged by developer. (Thu, 17 Nov 2011 19:39:04 GMT) Full text and rfc822 format available.

Message #178 received at 594150-done@bugs.debian.org (full text, mbox):

From: Alessandro Ghedini <al3xbio@gmail.com>
To: 594150-done@bugs.debian.org
Subject: Closing
Date: Thu, 17 Nov 2011 20:35:12 +0100
Version: 7.21.3-1

I'm closing this, since the problem in curl seems to be fixed.

Cheers





Reply sent to Alessandro Ghedini <al3xbio@gmail.com>:
You have taken responsibility. (Thu, 17 Nov 2011 19:39:04 GMT) Full text and rfc822 format available.

Notification sent to Johannes Ernst <johannes.ernst@gmail.com>:
Bug acknowledged by developer. (Thu, 17 Nov 2011 19:39:04 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 16 Dec 2011 07:35:04 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 19:25:36 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.