GnuTLS/NSS interop in Exim 4.80 RC
Phil Pennock
help-gnutls-phil at spodhuis.org
Tue May 22 10:24:27 CEST 2012
On 2012-05-22 at 09:47 +0200, Nikos Mavrogiannopoulos wrote:
> On Tue, May 22, 2012 at 8:48 AM, Janne Snabb <snabb at epipe.com> wrote:
> > Maybe you were unconsicously planning to file a bug about the misleading
> > EOF handling? :) I think we both wasted several hours of debugging time
> > because of that.
> > If a new error code can not be introduced due to API compatibility
> > reasons, the debug output should at least clearly indicate what happened
> > (instead of "ASSERT: somefunction(): NNN").
>
> Hello,
> I don't really understand what you mean here. Is there an issue in
> gnutls we can somehow improve?
When we were tracking down the NSS interop issue, we were both led a
little astray by one error return.
<gnutls/gnutls.h> says:
#define GNUTLS_E_UNEXPECTED_PACKET_LENGTH -9 /* GNUTLS_A_RECORD_OVERFLOW */
The error message was "A TLS packet with unexpected length was
received."
The problem is that *no* TLS packet was received. Instead, there was an
EOF condition. (Okay, sure there's a TCP RST involved, but that's not
TLS).
I spent a bit of time looking for the extra packet, and not seeing it in
ssltap/etc this is what led me to initially wonder if there was stale
data being left behind from a previous packet to GnuTLS.
If it can be accomplished without real interoperability issues, a
separate error code for EOF would really help with diagnosis.
Thanks,
-Phil
More information about the Gnutls-help
mailing list