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

Re: RFC: Encrypting ~/.subversion/auth on Windows

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-11-13 02:02:55 CET

On Nov 12, 2004, at 5:17 PM, Branko Čibej wrote:
>
> Yes. And it would be useless for my purpose. We've all agreed before
> that security through obscurity is a cure worse than the disease.
>

On Nov 12, 2004, at 5:35 PM, Ben Reser wrote:
> The purpose here is to make it so users don't
> have to enter anything to gain access to repos. We can't secure that
> and we shouldn't.

Guys, please stop redefining the problem. I never claimed I was
providing security, or that doing a rot13 operation on the password was
secure. I told you exactly what problem my proposal solves: users
accidentally getting glances of passwords. This is the complaint I
hear over and over and again.

> As far as administrators glancing at passwords. I simply don't buy
> that
> as a valid argument. If the person is an admin then they are an admin.
> They already have access to more than that person anyway.

Again, this assuming that the goal is "security". It's not. Of course
the root user can go and peer into a chmod 700 ~/.subversion/auth
directory and see the password. He just doesn't want to see it by
accident, when tarring up somebody's homedir for backup, or whatever.
People complain about this to me all the time, in email, IRC, and IM.
Maybe I'm living in an alternate reality. :-)

>
> Further the primary argument about admins glancing at passwords is
> about
> the svnserve password setup not the client side.

Not true. I see many more complaints about the client-side cleartext
passwords than the server-side ones. Heck, there's even a FAQ for it!
(http://subversion.tigris.org/project_faq.html#plaintext-passwords)

You guys are totally right about rot13 passwords being no more secure
than plaintext passwords, there's no argument there. Until we get
something like an 'svn-agent' daemon written, there will never be a
"secure" caching solution. And many svn users already recognize this.
(For example, a number of our customers simply disable svn password
caching altogether.)

But in the meantime, there's a still small tangential problem that can
be solved, one that CVS provides, and users have come to expect. Let's
not mix the two problems:

   1. solve the 'glancing' problem with a trivial scramble,

   2. file an issue to create some kind of svn-agent daemon, for real
security.

I'd much rather see effort put into #2, rather than new win32-specific
crypt calls. I agree with Ben -- in the meantime, put Branko's
recommendation into a FAQ or something.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 13 02:04:10 2004

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.