[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: handling of sasl packet sizes (ITS#2184)

   Date: Sun, 1 Dec 2002 05:33:19 GMT
   From: Howard Chu <openldap-its@OpenLDAP.org>

   Your patch has been committed, but I think the distinction you're
   drawing is somewhat obscure. The maxoutbuf tells the maximum buffer
   size that the remote client will accept. I think it's fair to
   expect that this also the maximum buffer size the remote client
   would ever send, and thus anything larger than that is an anomaly
   worthy of a warning message. (Note that it was not treated as a
   fatal error.)

It might be fair to expect, but that assumption is certainly not
covered in any protocol document. A busy server might want to have
small receive buffers (it gets lots of small commands frequently) but
large send buffers (so that it can efficiently send lots of data to a
few clients at a time).

   I note that there are still buffer size bugs in Cyrus SASL 2.1.9;
   the digestmd5.c and srp.c mechs still limit buffer sizes to 0xFFFF
   instead of 0xFFFFFF as required by RFC2222. There really should
   have been a manifest constant defined for this in the Cyrus headers
   to prevent these problems in the first place. Currently we have
   SASL_MAX_BUFF_SIZE defined in libldap's ldap-int.h (at 65536, which
   is off by one) and this value should have come from sasl.h, it
   should not be OpenLDAP's responsibility to define this value.

I don't understand what you're concerned about. OpenLDAP can set this
value (input to the SASL library) to any number it wants. The SASL
library will ensure correct on-the-wire behavior.

RFC 2222 doesn't require any sort of minimum supported buffer size.

There might be individual mechanisms with smaller limits than what
OpenLDAP supports, but this will not cause any interoperability