Cyrus SASL 2.1.25 Released

[Julien ÉLIE]

Hi Alexey,

>>> * Fixed a crash caused by aborted SASL authentication
>>> and initiation of another one using the same SASL context.
>>
>> http://inn.eyrie.org/trac/changeset/8045
>>
>> Does it mean that this patch is no longer necessary with Cyrus SASL
>> 2.1.25?
>
> I think this patch should stay and it is safe.

OK.


>> http://inn.eyrie.org/trac/changeset/8044
>
>> It appears that sasl_decode64() returns SASL_CONTINUE instead of
>> SASL_BADPROT when there is a base64-encoding error.
>
> sasl_decode64 can return a number of error codes (SASL_BUFOVER is
> another one) and relying that it will always returns SASL_BADPROT is a
> bad coding practice, IMHO. Everything != SASL_OK should be treated with
> the exception of SASL_CONTINUE. SASL_CONTINUE is only returned when
> there is an incomplete base64 string. Whether this is an error or not,
> it depends on the application. I.e. if there is no more data coming,
> then it is an error.

All right, many thanks for your answer.
We do not rely on SASL_BADPROT.  Other error codes are caught and 
properly displayed.  The NNTP protocol (RFC 3977 + RFC 4643) has a 
special 504 answer for base64 errors; that's why a response code 
different from SASL_BADPROT causes a problem when we strive for RFC-3977 
compliance.

Yes, you're right when saying that we know that no more data will come. 
  So, basically, I am using:
   response =
     (sasl_response == SASL_CONTINUE ? SASL_BADPROT : sasl_response);
which properly catches all error codes, as well as SASL_OK.

-- 
Julien ÉLIE

« Le chemin le plus court d'un point à un autre est la ligne droite,
   à condition que les deux points soient bien en face l'un de
   l'autre. » (Pierre Dac)