Ryan Schmidt wrote:
> On Nov 11, 2005, at 17:37, Gale, David wrote:
>>> I think it would be better to not store passwords, but only their
>>> hashes, just like Apache does. Maybe a htpasswd-like tool should be
>>> added to svnserve?
>> And a command to the svn client to allow the user to change their
>> password, since currently there's no way to change a user's password
>> without having the admin do it, which isn't a friendly thing...
> Let's not get carried away, please. a) That's not what this thread is
> about, b) it's been discussed many times before, and c) it's not
> possible to do cleanly because each access method has a different way
> of handling passwords-for svn://, it's a password file. For file:///,
> it's filesystem permissions. For svn+ssh://, it's a shell account.
> For http:// and https://, Apache could be configured in half a dozen
> different ways, from htpasswd files to LDAP and PAM authentication.
> It's not reasonable for Subversion to need to know how to change
> passwords for all these scenarios, and there already exist plenty of
> existing ways for htpasswd files to get changed, for LDAP and system
> user passwords to get changed, and so on. So it's not unreasonable to
> place the burden on the system administrator to install a tool that
> lets users of her particular Subversion setup change their passwords.
I'm not so sure this qualifies as "getting carried away". To your
a)Point taken. Starting a new thread.
b)I haven't seen it discussed, and have been monitoring the list for a
while; this isn't merge tracking, which comes up at least once a week.
Yes, I could probably revive a months-old thread by searching through
the archive, but that seems like it'd be silly.
c)You actually make a pretty good argument *in favor* of adding a tool
specifically for svnserve'd repositories. Every other access method
either doesn't have passwords (file:///), or has tools available that
allow users to change their own passwords, as you point out; it's
trivial to expect administrators to install these tools. However, for
svnserve, there isn't a tool to be installed--the administrator would
need to create one, which is far less trivial. As I read the book,
svnserve is supposed to be a perfectly acceptable equivalent to
http[s]://, but it is the only method that requires the administrator to
create a new tool from scratch (or else manually maintain the file).
With the passwords in plain text, this isn't too hard for anyone _who
knows how to program_, but it's very possible that the repository
administrator is not a programmer. (Changing to encrypted passwords
would probably entail the creation of a server-side tool, so the
client-side tool could just call that, conceivably; this would actually
make creating such a tool easier, though still not something for a
non-programmer.) And, of course, if the team uses multiple OS's, the
tool would need to be available on each OS, which is beyond the scope of
most casual programmers. (It can't be simply a web page, because many
servers only have the command line available.) And I haven't even
mentioned that the tool would need to speak the svn protocol, in case
the server is behind a restrictive firewall. Or figuring out how to
authenticate users before changing their password, especially once/if
the passwords are stored in encrypted form. The subversion client
already has the necessary framework in place.
As to the fact that this would be creating a part of the subversion
client that only works for one specific access protocol out of the
several available: this is true, but I'm not really sure how it can be
viewed as a valid argument against it. It'd be trivial to check the
access method and spit out an error message immediately for anything
other than svn. There're already parts of subversion that are
option-specific (for instance, "svnadmin list-unused-dblogs" doesn't
work on FSFS repositories), so it's not breaking any precedents. And,
finally, svnserve is "a custom server" (quoting the book); expecting
third parties to further customize it to provide such basic
functionality is, well, a bit odd, frankly.
Having said all of that, I'd be interested in hearing any arguments why
the subversion client should not have a tool for changing user's
passwords for svnserve'd repositories, or why proposing such a tool is
"getting carried away".
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Nov 11 20:24:38 2005