After recompiling mutt with openssl instead of gnutls I discovered that
openssl was also affected, so I tried another USB ethernet dongle and
that seems to have fixed it. At least I can't reproduce the problem with
the large IMAP fetch using openssl s_client. I've now blacklisted the
module for the
Sorry, I spoke too soon, I was just able to reproduce it on the new NIC,
but it happens much less often.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1419436
Title:
tls_socket_read (Decryption has
Donn, was it a different kind of usb NIC or the same kind? Perhaps
there's a kernel bug to fix or perhaps you just need to throw away the
old NIC, depending upon what changed.
Thanks
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
htt
Yes, I realise that now. I've tried on a Raspberry Pi with 2.12.20 (armhf)
without problems. What is curious is why it was working before under Ubuntu
12.04. Comparing tag and tag_ptr, I can say that it is in fact the HMAC that
differs, and not the padding check. I'll keep debugging.
On Mon, Feb 0
It appears your patch disables authentication entirely; if I'm correct,
a MITM attacker can modify bytes at will and you're unlikely to discover
that they have been modified while in transit.
I'm sorry that I don't have anything better to recommend; it'd be worth
running some stressors on your har
I dug a little deeper and recompiled gnutls28-3.2.11 from sources
provided by "apt-get source" and commented out the block at
gnutls_cipher.c:951(see snippet below) which caused the first assertion
in the log above. This fixes the problem, that is, I can download
attachments in mutt seemingly witho
