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

Re: [PATCH] Change default "store-passwords" policy to "no"

From: Michael Haggerty <mhagger_at_alum.mit.edu>
Date: 2007-10-11 16:37:34 CEST

Mark Phippard wrote:
> On 10/11/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> This patch changes the default behavior so that SVN does *not* store
>> passwords to disk in the default configuration.
>> [...]
> These are only issues on *nix. Windows and OSX both store passwords
> with strong encryption. I'd be an emphatic -1 to changing the default
> behavior on those operating systems.

Do Windows and OSX store the encrypted passwords on the filesystem "in
the /auth area of your config directory" (the quotation is from the text
that is currently written to the config file)? I was under the
impression that they are stored somewhere else (in some registry or

Maybe there needs to be another "store-cleartext-passwords" option that
is consulted to decide what to do iff no password encryption facility is

> I know we cannot do strong encryption on *nix without dragging in a
> bunch of dependencies. Is there something else that can be done?
> I'd also be opposed to this patch unless we are going to implement
> better (actually we don't have any exposed in JavaHL) API's for
> working with the configuration files. I am kind of stuck when dealing
> with these issues in Subclipse because I do not have any way to
> examine or update the configuration other than going at the files
> directly. Given that Subclipse is platform independent and the rules
> for the configuration files are not, this is not trivial.

Give that Subclipse is platform-independent, how does it hook into the
platform-dependent password encryption machinery? Wherever that is,
couldn't the password-saving decision (including consultation of the
config options) be done there?

The current situation is inconvenient and risky even if it "only"
affects *nix. It would be great if the default could be made more


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 11 16:38:04 2007

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.