On 7/16/06, Nico Kadel-Garcia <nkadel@comcast.net> wrote:
> gmu 2k6 wrote:
> > On 7/16/06, Nico Kadel-Garcia <nkadel@comcast.net> wrote:
> >> gmu 2k6 wrote:
> >>
> >>> sorry, but I don't want to have any sort of http-daemon running at
> >>> all. actually I also have OpenSSH running and that together with
> >>> svnserve is enough of an attack vector besides the ineviatable but
> >>> securable tcp/ip stack itself.
> >>> running too many services on one box is not good, security and
> >>> performance-wise. I'm trying to keep both Dual-Core CPUs free for
> >>> all the hard work
> >>> svnserve does when updating/committing (actually I'm happy svnserve
> >>> can saturate the CPU but this naturally does not leave much space
> >>> for additional services).
> >>
> >> Hmm. How do you allow the users in to change their passwords, then?
> >
> > they tell me they want a new password and I send them one. if I allow
> > them to send a mail to an auto-reply bot 1) we need an SMTP server and
> > 2) also some sort of authentication. the company is small enough to
> > ignore social engineering
> > for the inside.
> > company-mail-server username = svn username
> > ergo:
> > $change_and_mail_new_svn_pwd <username>.
>
> *AHH*. In that circumstance, I'd send them an email telling them to me on
> the phone, with a published number, and read it to them. And I've done that
> inside a company where I know or can find the office of everybody: I'd never
> even think to do that in a large environment, or one with outside agencies
> requiring access.
yeah, it is sub-optimal, but internal emails with passwords that are
10 to 20 characters with a well-defined complexity-policy is better
than letting users choose trivial passwords for svn's passwd file
besides their already-existent Windows AD passwords.
> > of course using LDAP or Active Directory (which is available) would be
> > better but svnserve is the only way to go because of
> > performance/scalability reasons.
>
> You found issues with HTTPS/mod_dav_svn? What's the performance issue?
svnserve does not have to tunnel the traffic in HTTP(s) or SSH which
needs resources on the server managing the repo. if noone tells me
that HTTPS or svn+ssh is faster than plain svn:// I see no reason to
depend on additional tunneling.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jul 16 16:16:24 2006