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

Re: [Bug] "store-passwords = no" plus upgrading from 1.1->1.2 (or later) removes existing cached passwords

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2005-09-23 18:26:51 CEST

On Fri, Sep 23, 2005 at 03:40:34PM +0100, Max Bowsher wrote:
> Malcolm Rowe wrote:
> >That seems correct to me: with 'store-passwords = no', you're requesting
> >that the client, well, not store passwords (or more correctly, to cease
> >caching the password responses to server challenges). That the client
> >doesn't proactively remove existing passwords from the cache when started
> >with store-passwords=no is the real bug her, in my opinion (and no,
> >not one worth worrying about either).
> Regardless of your opinion about the definition of store-passwords,
> removing a password from the cache purely as a side effect of a transparent
> upgrade is *definitely* a bug.

Apologies - I misinterpreted the documentation on store-passwords. Given
that, what I really should have said is something like this:

The book's definition of store-passwords actually allows for two
correct behaviours, because it isn't clear whether the choice to cache or
not to cache takes effect only at the point when the user provides a
correct password, or is something that applies at all times.

The former is the current (and, I'm guessing, intended) behaviour, the
latter is the behaviour that I inferred from reading the documentation
(from the sentence that reads, in part, "This instructs Subversion to
cache, or not to cache, passwords").

> In response to your opinion,

.. which was based on a misinterpretation of the existing documentation,
and so should now be more accurately termed a 'misunderstanding' than an
opinion, sorry. :-/

> Also, purging data as a side effect of a configuration option is far too
> open to causing unpleasant surprises.

However, if you had interpreted 'store-passwords=no' as 'never store
passwords', as I had, it would be the behaviour you'd expect.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 23 18:27:37 2005

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.