[m68k] Re: gnutls26 confirmed broken (was Re: [buildd] apt-transport-https segfaults)

[Thorsten Glaser]

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