Segfaults with SASL

[Julien ÉLIE]

Hi Russ,

> This rings a vague bell.  There was some sort of change in the decoding of
> the Cyrus SASL libraries recently, I think.  Maybe:
>
>    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400955
>
> is related?
>
> | The new Cyrus SASL has a partially rewritten sasl_decode64 function,
> | which is stricter and more complete than the old one. However, it seems
> | that applications (at least imtest) assume they can pass in a
> | CRLF-terminated string. The code anticipates this in a comment, but
> | doesn't actually implement CRLF-ignoring at the end of the string.

No relation, unfortunately.  There is no problem with CRLF in the way
SASL was implemented on INN.


>> The last thing I see is that the SASL server needs to be renewed.  That
>> is to say if the authentication fails, we have to dispose of the
>> connection and start a fresh new SASL server, waiting for a connection.
>> (But I do not see why the second attempt if the connection is not
>> disposed, will work in our case.)  Do you think it is the right use of
>> SASL?
>
> I'm afraid I really don't know here.

I have tried to dispose of the connection and restart the SASL server with
a new connection in case of a failure in the attempt of connecting
and it solves the problem:

AUTHINFO SASL DIGEST-MD5
383 bm9uY2U9Ik[...]XNlc3M=
AUTHINFO SASL DIGEST-MD5
504 bad protocol / cancel
AUTHINFO SASL DIGEST-MD5
383 bm9uY2U9Ik[...]XNlc3M=
AUTHINFO SASL DIGEST-MD5
504 bad protocol / cancel


AUTHINFO SASL DIGEST-MD5
383 bm9uY2U9Ik[...]XNlc3M=
aQ==
481 authentication failure

It is very fine!
Therefore, I believe the problem was that the SASL server had to be restarted.
Bug fixed :)

-- 
Julien ÉLIE

« -- Tu dois avoir un messager zélé autant qu'ailé
  pour faire rapidement le trajet.
  -- Oui ! et c'est une fine mouche ! » (Astérix)