On Sun, Aug 01, 2010 at 12:59:08PM -0400, Nico Kadel-Garcia wrote:
> >> I've given a few specific examples. While it's gotten better and
> >> you've addressed some of my concerns, my overall concerns still stand.
> >> Cleartext password storage is a big problem, frequently ignored by
> >> deployers and developers who don't realize it's still there and who've
> >> never had to clean up the mess when someone leave passwords on a
> >> laptop or an NFS fileshare.
> >
> > Yes. But I'm not convinced adding another config knob to enable it
> > will fix that. People who favour comfort over security will just
> > enable it.
>
> The "config knob" already exists, seriously. It's in the default
> .subversion/config file, in these two lines:
>
> # This should be uncommented, and the binary tweaked for it to be
> "no" by default
> store-passwords = no
That turns off storing any kinds of passwords (even encrypted).
> # This should be uncommented, and the binary tweaked for it to be
> "no" by default
> store-auth-creds = no
That turns off even more, e.g. svn won't even store server SSL certs
if you set store-auth-creds to 'no'.
As of 1.6.x, there is also a 'store-plaintext-passwords' option
which controls the prompting behaviour. Valid values are 'ask' (default),
'yes', and 'no'.
> The syntax of .subversion/config is, unfortunately, somewhat
> confusing. For most such config files, the defaults are left in the
> file, commented out. It's only when someone wants to change them that
> they uncomment specific lines and modify their content: uncommenting
> the line normally changes nothing in most such config files, such as
> /etc/ssh/sshd_config or /etc/postfix/main.cf.
> For whatever historical reason, the authors of this config file chose
> to use an alternate layout with alternative settings commented out,
> instead of the standard settings.
Well, that's a pretty arbitrary convention.
I think I've seen both ways of doing it.
In Subversion, the default value of an option, and all possible values,
should be contained in the comment explaining the option.
If that's not the case, please point out where, and we'll fix it
(or you can send a patch, the file is generated by libsvn_subr/config_file.c).
> >> > Please raise the issue again when Subversion 2.x comes around.
> >>
> >> What is the timetable for that?
> >
> > None so far :)
>
> Ahh. Vaporware.
Yes! 2.0 is a running gag.
> Then I'd like to give me a pony everytime I
> successfully do a code merge. And a little man with a bucket and
> shovel to clean up after the pony everytime I do a successful tagged
> release.
Sure. Order forms for ponies are available on request at the office
near the very end of the next nearby rainbow, should you see one.
> >> The difficulty lies in *preventing* people with such password based
> >> access from using the command line "svn" tool and storing the
> >> passwords behind your back, in the face of such education.
> >
> > Well, that's a social problem to be solved, not a technical one.
> > No amount of technical lock-down will fix the social problem.
>
> Locking down the default .subversion/config file settings to refuse to
> store authentication tokens without manual intervention would be a
> helpful first step.
If you want that, set store-plaintext-passwords = no.
Or run OpenBSD, where the default value of the option is 'no' instead
of 'ask', as dictated by the system wide config file in /etc/subversion/.
Stefan
Received on 2010-08-01 23:20:25 CEST