Bug#594150: regression in apt-transport-https interop with apt-cacher

[Simon McVittie]

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