[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: store-password = no --> server certificates are not stored any more

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-11-07 02:52:31 CET

Jani Averbach <jaa@cc.jyu.fi> writes:

> On 2003-11-06 18:29-0600, Ben Collins-Sussman wrote:
>>
>> Yes. We need to rename that variable to "store-credentials". It
>> activates/deactivates disk caching of *all* credentials (passwords,
>> server certs, etc.).
>
> I don't know where I have been when this is decided, but IMHO, this
> is not a good thing to do (tm).
>
> Reason:
> I would have very well environment where I like authenticate my svn up
> data by using ssl + server certificate, but I don't want store my
> credentials (password) on the disk.
>
> So if this will proceed like planned, above setup is not possible, right?
> Or am I supposed to use --no-auth-cache?
>
>>
>> Any volunteers? :-)
>>
>
> It depends on answer of above questions. =)

When originally introduced the store-password option controlled
whether the password was stored in the working copy, but it did not
affect the username which was always stored (the --no-auth-cache flag
would override store-password and cause neither password or username
to be stored in the working copy.) At some point the auth storage
stuff got reworked and the behaviour of store-password changed, it
started to affect both username and password. I didn't like this
change but the auth stuff has so many layers, not to mention an
interface I dislike, that I never got round to doing anything about
it.

I would like to be able to store usernames, certificates, etc. without
storing passwords.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 7 02:53:18 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.