Simon Josefsson wrote:
If someone find them useful, I suggest adding that the value '0', when integrity/privacy layers are installed, means that the peer that sends that value does not have any limit on the maximum packet size.This would be inconsistent with several other SASL mechanisms (GS1 and DIGEST-MD5). Cyrus implementation is using 0xFFFFFF in this case.A maxbuf value of 0 has weird semantics -- it is a error-state, and authentication using a maxbuf=0 value with security layers should not succeed.
Yes. (So is maxbuf=1)
I would like to have consistency accross multiple SASL mechanisms. GS1 or DIGEST-MD5 don't treat 0 specially.It seems simpler to use it to signal something else (i.e., no buffer size limit) than to use 0xFFFFFF for the same thing on the wire AND ALSO describe the behaviour for the error state.
If you insist on using 0 in way different from GS1 and DIGEST-MD5, please stick a big note saying that GS2 is different from GS1 in handling of maxbuf==0.Effectively, my approach removes an error-state.
Also, Cyrus should have no problem in mapping a 0-value on the wire to a maxbuf value of 0xFFFFFF internally, right? My implementation uses SIZE_MAX to signal the same in the APIs.