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

Re: svn commit: r30723 - in branches/dont-save-plaintext-passwords-by-default: . subversion/include subversion/libsvn_subr subversion/svn

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Tue, 22 Apr 2008 10:10:45 -0400

Stefan Sperling <stsp_at_elego.de> writes:
> Actually, storing 'store-plaintext-passwords' in 'servers' is *required*
> to fix the following bug I just realised exists (and is really silly
> once you realise it's there, I do really stupid things sometimes):
> In svn/main.c on the branch, we're currently grabbing URLs from the
> command line so we can use those to match server groups in the 'servers'
> file. The approach is totally naive and wrong. We're not even checking
> (and we can't, in main.c) which of the URLs we're actually connecting to
> (they might be part of, say, a log message argument), and on top of that,
> the URL we're connecting to might not even be retrieved from the command
> line! "svn ci ..." causes auth data to be cached for repos that require
> auth only for write operations, like our own repo does. Doh!
> So this is clearly an issue of "layer violation". 'store-plaintext-passwords'
> has to move out of 'config' and svn_cmdline_setup_auth_baton, and go into
> 'servers', and be evaluated by RA layers. This probably means that quite a
> bit of code will need to be refactored/rewritten on the branch :/
> Does anyone oppose moving the whole [auth] section from 'config' to
> 'servers' for consistency?

As long as we maintain compatibility...

But why is there a connection between which file the "[auth]" section
lives in (a user-visible question) and which URLs we use that data for
(an internal code-flow issue)?

The choice of which config file to use should be made based on what will
make most sense for users, who don't know or care how our code is
organized internally. It sounds like these two issues are maybe getting
mixed together, in your comments above?


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-22 16:31:02 CEST

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.