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/
Attachment:
pgpenDhlvamk4.pgp
Description: PGP signature