On Thu, Jan 6, 2011 at 1:29 AM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
> On Wed, Jan 5, 2011 at 2:19 PM, Les Mikesell <lesmikesell_at_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
Received on 2011-01-06 09:40:17 CET