Re: Configuring encrypted password caching: API proposal

On Fri, Oct 17, 2008 at 1:49 PM, David James <james82_at_gmail.com> wrote:
> On Thu, Oct 16, 2008 at 4:32 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>> On Thu, Oct 16, 2008 at 09:17:38AM -0700, David James wrote:
>>> Right now, our API for configuring encrypted password caching is
>>> rather difficult to use. Right now, user applications which want to
>>> use encrypted password stores must configure their application to load
>>> different libraries and call different functions depending on what
>>> password stores are available. I think that we should simplify our API
>>> so that users can use encrypted password stores without writing their
>>> own code to dynamically load the appropriate libraries.
>>>
>>> The simplest possible API for loading encrypted password stores would
>>> be an API that simply allowed users to specify the type of the
>>> provider they want, and then we would return the provider if it is
>>> available.
>>
>>> Thoughts?
>>
>> Sounds like a great idea to me.
>>
>> What types of providers do you have in mind exactly?
>>
>> Do you want users to be able to say e.g. "I want KDEWallet"?
>> If so, I'd rather not call it a 'type', but just a 'name' for
>> the provider.
>>
>> But maybe users would rather like to ask for things like: "I really
>> want a provider which will encrypt the password." Or: "I want a provider
>> which either encrypts the password or saves it in plaintext with
>> the user's consent" (this would currently match any available one).
>>
>> This is fairly high-level, but given that you want to abstract
>> from system details, this would make sense, wouldn't it?
>
> I want to allow users to be able to select the same providers they can
> do now with the current approach. In the case of kwallet, there are
> actually two providers: kwallet_simple_provider, and
> kwallet_ssl_client_cert_pw_provider. In my API proposal, users would
> be able to select these providers separately. Users who want both
> providers would need to ask for each provider in a separate function
> call.

I do not understand our architecture. I use JavaHL via Subclipse so
code can run on any OS. Why would I want to ask for any of this? I
do not see why we even expose this. Subversion ought to just know
what it can do and do it. If we have multiple options on an OS then
let the user configure their preference on config area.

Also, why did we have to do all this work to get SSL cert passphrases
supported? It seems like we ought to just have an ability to store
key/value pairs (passwords) and if there is a secure mechanism
available to do it .. use it.

I was pretty shocked to discover that 2 releases after we added
keychain support on OSX that JavaHL did not even support it because no
one had added the boilerplate code to the library to ask for it. It
seems we are broken in this area if that code even needed to be added.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org