Next release of CMU SASL - update

Patrick Ben Koetter p at
Sat Apr 11 15:16:24 EDT 2009

* Alexey Melnikov <alexey.melnikov at>:
> Patrick Ben Koetter wrote:
>> * Alexey Melnikov <alexey.melnikov at>:  
>>> The date is approaching and I don't think we are quite ready. In 
>>> order  to keep things moving I will do weekly status reports with the 
>>> list of  bugs/issues I still need to look at. Here is my current list 
>>> (in no  particular order):
>>> 1). Remove extra (unused) mutex in libsasl
>>> 2). Merge my utils/pluginviewer.c changes
>>> 3). Investigate global callback updating in subsequent   
>>> sasl_server_init() calls
>>> 4). Commit SQLite3 configure change. Test SQLite3 plugin.
>>> 5). Remove use of obsolete cmusasl... attributes
>>> 6). Strip trailing spaces from options during server configuration loading
>>> 7). Investigate fix for bug # 2822 (OTP does not work with prompts)
>>> 8). Review patch for bug # 3134 (Improved error reporting from   
>>> auth_getpwent)
>>> 9). MacOS dlopen.c change (+ the libtool change?)
>>> 10). Merge Debian bugfixes
>> I stumbled over this a while ago and believe this should work differently:
>> Consider this:
>> mumble.conf in /usr/lib/sasl2/ and /etc/sasl/.
>> Currently, if mumble.conf is found in /usr/lib/sasl2/ it will be used instead
>> of /etc/sasl/.
>> I believe it should it be the other way around. If mumble.conf is found in
>> /etc/sasl/ it takes precedence over /usr/lib/sasl2/mumble.conf.
>> /usr/lib/sasl2/, to me, is the (old) default and fallback dir.
> I probably did this to preserve backward compatibility.

>From my point of view it doesn't break backward compatibility; it keeps
backward compatibility and (!) gives forward compatibility too:

backward compatibility
    If someone decides to put config files in /usr/lib/sasl2/ and never even
    bothers to put things in /etc/sasl/ things stay as they have always been.

forward compatibility
    If someone decides to use /etc/sasl/ things work - even if legacy config
    files "hang around" in /usr/lib/sasl2/.

Both work. If /usr/lib/sasl2/ always overrides settings in /etc/sasl/ only
/usr/lib/sasl2/ works reliably.

p at rick

All technical answers asked privately will be automatically answered on
the list and archived for public access unless privacy is explicitely
required and justified.

saslfinger (debugging SMTP AUTH):

More information about the Cyrus-sasl mailing list