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

[Johannes Ernst]

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