RFC auxprop enhancement

[Alexey Melnikov]

Pierangelo Masarati wrote:

>>On Mon, Dec 19, 2005 at 10:04:25AM +0000, Alexey Melnikov wrote:
>>    
>>
>>>I am not sure that #2 is required, if the change #1 is done everywhere.
>>>      
>>>
>>But #1 looks like a backwards incompatible ABI change, and if the
>>plug-in SPI is public, then this seems like an inappropriate change --
>>unless you're doing a major revision to Cyrus SASL or provide for
>>backwards compatibility with third party plug-ins that don't do #1.
>>    
>>
>
>As usual, the evil is in the details; I didn't consider all the related
>issues yet in detail, but of course they'll have to be considered before
>we get to actual programming.
>
>I have a few comments, though.
>
>1) IMHO we're speaking of something that should actually be deprecated,
>because password-based auth that requires storing the password in
>cleartext on a DSA to allow things like history and so is not exactly the
>best solution in terms of overall security; however, based on what we
>currently develop and deploy, password-based auth will be used for quite
>some time, while password policies are getting requested more and more
>often;
>
>2) looking at the existing official auxprop plugins, it appears that at
>least the SQL one, but also the sasldb one may benefit from this change,
>because right now they simply don't set the auxprop in a number of cases
>where a more meaningful error could be passed to the library (this oes not
>mean to the client: an "invalidCredentials" error is the right thing to
>return, but the server-side library may benefit from better knowledge of
>the reason the auxprop couldn't be collected).
>  
>
Exactly. Lack of meaningful error codes was a problem for me when I was 
trying to impelement "rename user" functionality.

>3) I favor allowing backwards compatibility with auxprop plugins that do
>not exploit these new features.  In fact, this API change should be
>considered optional, since it adds functionalities that are essentially
>useful when enforcing a password policy, so if possible, the library
>should be able to handle plugins that do not use these features (if this
>compatibility is worth the effort, of course).
>  
>
I haven't made my mind on this issue yet, but I think preserving 
backward compatibility (i.e. allow SASL library to work with old auxprop 
plugins) might not be worth the code complexity and could cause security 
risks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.andrew.cmu.edu/mailman/private/cyrus-sasl/attachments/20051230/59eb9de1/attachment.html