On 10/11/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> 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
> whatnot).
On Windows it is stored in auth area. The value is encrypted. OSX
uses the Keychain service.
> Maybe there needs to be another "store-cleartext-passwords" option that
> is consulted to decide what to do iff no password encryption facility is
> available.
That seems like one possible way to do it.
> > 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?
We are not directly involved in the process. We get a callback (or
not) and Subversion decodes. The problem is that telling our less
technical users to find their config file and edit it really sucks.
We already have to do this today for things like SSH configuration and
it really, really hurts us.
> The current situation is inconvenient and risky even if it "only"
> affects *nix. It would be great if the default could be made more
> conservative.
I understand what you are saying, but other than the occasional
flare-up on users@ I do not see where it has been a big issue. I'd
rather see us direct our energy towards a solution where the passwords
are encrypted in some way.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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:49:44 2007