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)
