Cool ideas everyone, although each seems to have tradeoffs.
The svn+ssh approach is cool, although we would give up the Active
Directory integration. One of the things that is great about svn https
is that we are using Active Directory which was requested by the
security guy. This centralizes access so that we only have one place to
go when we want to remove access to a resource.
For the person who asked if we used cvs, no we used Perforce. I doubt
that is more secure than svn. Even having the passwords, hashed or
something might be better than complete plain text. Security Guy is
worried about someone running over to a machine after someone went to
go for a break, looking in the files and getting the cleartext. Perhaps
a hash like cvs would be better but I am sure he still would not be
completely satisfied with that. That would a least prevent someone from
accessing another computer with that password because the hash would
only work with svn.
Another possibility, that someone suggested, is writing some sort of
shell script that caches the password. We would turn off caching. This
might be an immediate solution that would not be hard to implement,
however his also might restrict the full set of commands available.
Also our TortoiseSvn users would not be happy with this. Seems like
Tortoise could cache the password in its process, but I am pretty sure
it does not.
The another solution which sounds the most appealing to me is the SSH
agent style approach. This might solve it in all situations.
Another possibility that may completely solve the problem is Kerberos
authentication rather than auth_ldap and AD, but may be tricky to
setup. Does anyone have experience with this? I found mod_auth_kerb
does this work?
The last solution, being advocated by Security Guy, which requires the
least amount of change, is to turn off the cache and make people type a
lot of passwords. Does anyone have experience with this and how
annoying it is? He is judging that we might have maybe 10 commands per
developer per day where we have to enter our passwords, since it is
only the commands talk to the server that need to authenticate. I would
guess it is more like 20-50.
- Paul
On Aug 25, 2004, at 4:49 PM, Travis P wrote:
>
>
> On Aug 25, 2004, at 6:07 PM, Peter Valdemar Mørch wrote:
>
> > Travis P svn-at-castle.fastmail.fm |Lists| wrote:
> >> It can lead to something entirely sensible like ssh-agent or AFS
> >> tokens.
> >
> > Well, to be practical for Paul Ossenbruggen, this is a real world
> > solution, that works NOW: Use ssh to access the repository instead
> of
> > http. svn co svn+ssh://server/repos/path/
>
> Definitely a good solution that can be deployed today, as long as you
> do not need per-path authorization granularity for reads and writes,
> something that only the DAV access method provides today. All other
> pros-and-cons of the different access methods apply of course. In
> this
> case, the ability to use ssh-agent and avoid on-disk auth caching
> while
> maintaining usability is a strong advantage of svn+ssh access, perhaps
> the defining one, but there are tradeoffs.
>
> -Travis
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Received on Thu Aug 26 04:02:39 2004