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