On Tue, 14 Jan 2003, [UTF-8] Branko Čibej wrote:
> rbb@rkbloom.net wrote:
>
> >On Tue, 14 Jan 2003, [UTF-8] Branko Čibej wrote:
> >
> >
> >
> >>rbb@rkbloom.net wrote:
> >>
> >>
> >>
> >>>Just for completeness, the security concerns are just as valid. On a
> >>>multi-user system, the password should not be stored on the disk by
> >>>default, especially not in plain text.
> >>>
> >>>
> >>>
> >>It wouldn't be a problem if you have an encrypted filesystem, of course;
> >>I wonder how hard it would be to encrypt the password?
> >>
> >>Oh, and BTW, regarding cert authentication with SSL -- the certs (or
> >>rather, the private keys) have to be password-protected, too, otherwise
> >>anyone can use them. Same problem, one level deeper.
> >>
> >>
> >
> >Yep, which basically means that we will need something like ssh-agent to
> >_really_ solve this problem.
> >
> >
>
> Well, then why don't we go for that immediately? Drop all this
> auth-cache vs. no-auth-cache thing, and write svn-agent daemon. Then we
> truly don't have to keep anything on disk. Of course, it does make
> client configuration a bit harder, but hey.
Because you still need the auth-cache stuff. :-) For the most common
case for subversion, you will have people setting up subversion for public
consumption, which means that not everybody will be able to use
client-side certs for authentication. It also means that not all
subversion servers will be run over SSL.
Yeah, client side config is even harder, because there are a lot of
options, but I can't find a way to get rid of any of them.
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 14 22:34:37 2003