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
Description: Digital signature
