On Thu, Jan 6, 2011 at 1:29 AM, Nico Kadel-Garcia <nka...@gmail.com> wrote: > On Wed, Jan 5, 2011 at 2:19 PM, Les Mikesell <lesmikes...@gmail.com> wrote: > >> Of course you _can_ secure it. My point is that permitting ssh and >> restricting access to ssh by itself is very likely to make your system less >> secure (if you count on firewall protections) instead of more so. And >> nothing that can be done in the default svn installation can fix it. > > It's an issue. The layers and layers of external-to-subversion hackery > to secure any of the multiple forms of access is fairly burdensome. > Coupled with the lack of configuration tools for the SSH key > management, and it's a compounded problem. Alternative port use, and > restricting a separate SSHD for external access with only a single > user allowed and access restricted to SSH keys, it's a lot better, but > those are extra and fairly painful steps. > > Mind you, compared to storing the HTTP/HTTPS passwords in clear text > in fashions that are unstoppable by the server and is enabled by > default in all UNIX and Linux clients, it's a 2 inch thick vault door,
Oh, come on. From the server side you can never control what I do as a user with my password. If I find it convenient to use the same password on facebook, there is not much you as a sysadmin can do about it. So if I'm on *nix, without gnome-keyring and KDE-wallet, and I decide to ignore the warning "this will store the password in clear-text in your homedir, are you sure?", which my sysadmin specifically instructed me *not to do*, that's basically the same thing. Well, it's actually vastly less severe than re-using that password for other (non-company) services, because the password is still only in a file that's in my homedir with permissions that make it readable only by me. Cheers, -- Johan
