Re: Next release of CMU SASL - update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Alexey Melnikov <alexey.melnikov@xxxxxxxxx>:
> Patrick Ben Koetter wrote:
>
>> * Alexey Melnikov <alexey.melnikov@xxxxxxxxx>:  
>>
>>> 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@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):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>

[Index of Archives]     [Info Cyrus]     [Squirrel Mail]     [Linux Media]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux