> Henrique de Moraes Holschuh píše v Út 05. 12. 2006 v 20:48 -0200: > > Also, currently sasl is (as you probably know) not being very forgiving of > > clients doing extremely dumb things (aka sending CR/LF/CRLF in base64 > > strings), might that be the problem?
FYI: On Wed, 06 Dec 2006 09:22:43 -0500, Ken Murchison wrote: > Applications are supposed to be stripping any protocol junk off of > the string and just pass naked base64. (That's from the cyrus-sasl (upstream) mailing list: http://asg.web.cmu.edu/archive/message.php?mailbox=archive.cyrus-sasl&msg=8216) Currently cyrus-sasl2 includes a patch that allows trailing CR/LF/CRLF. With etch in mind, we don't have time to track down and fix all packages that supply junk among the base64 data, but we should definitely start to hunt down all such cases. Unfortunately, for etch I think we're going to have to "hide" this bug in other programs by including this patch. After etch, dropping that patch in the unstable version is going to be among the first things on my list... In case someone is interested, the reason why some implementations permit "junk" inside the base64 data is probably that the MIME standard requires (RFC 2045, section 6.8) implementations to silently ignore non-base64 characters, and split lines every 76 characters. The actual base64 spec is defined in RFC 4648, in which section 3.3 explicitly says: "Implementations MUST reject the encoded data if it contains characters outside the base alphabet..." and goes on to allow an exception for this: "...unless the specification referring to this document explicitly states otherwise" (MIME being an example). Cheers, -- Fabian Fagerholm <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part