Dixi quod… >It doesn’t do that for me, but I can confirm that nongnu-tls is even >more broken than usual: apt-transport-https, lynx-cur and (since the >switch from the *working* OpenSSL to this beast) wget just sit there >and eat up a lot of CPU when trying to connect to e.g. https sites – >throwing openssl s_client on them works. > >So I guess something in gnutls26 or its dependencies broke somewhat >recently (possibly, within the last year or more).
Interesting… same numbers for two different servers, one a Debian/i386 wheezy with Apache 2 and mod_ssl, one MirBSD/i386 with Apache 1: ‣‣‣ wget 1.14-1 (gnutls26) libgnutls26_2.12.7-4 ⇒ 45s (via LD_PRELOAD) ii libgnutls26:m68k 2.12.20-2 ⇒ 64s ‣‣‣ wget 1.12-5 (openssl) ii libssl1.0.0:m68k 1.0.1c-4 ⇒ 1s Now that is a *noticeable* difference, even, granted, when the two servers (https://www.mirbsd.org/ and https://evolvis.evolvis.org/) have both 4096-bit RSA certificates. Cc’ing “non”gnu-tls maintainers, do you have any idea how we can track this down? Ingo even sees double-free/corruption – see http://thread.gmane.org/gmane.linux.debian.ports.68k/10653 – but I can still connect… most of the time. Not always, though. Cc’ing Noel, you said that the switch of wget away from OpenSSL was only temporarily, will it get reverted? (Granted, that will not help apt-transport-https… or lynx-cur…) bye, //mirabilos -- 13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good guy. But he's always right! In every fsckin' situation, he's right. Even with his deeply perverted taste in software and borked ambition towards broken OSes - in the end, he's damn right about it :(! […] works in mksh -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
