On Fri, Jan 7, 2011 at 11:43 AM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On 1/4/2011 8:25 PM, Nico Kadel-Garcia wrote:
>>
>> This is a very large and longstanding issue for me and others, and has
>> led to clients of mine rejecting Subversion outright. And it looks
>> like a legacy of Subversion's re-implementation of CVS, described as
>> "CVS done right". CVS security was even worse.
>
> I'd say instead that it looks like a lack of a suitable cross-platform
> security library - or more specifically a lack of a suitable OS facility in
> Linux to manage per-user application passwords.
No, the problem is more fundamental. This lack was not ever a good
excuse to enable plain-text password storage, especially as default
behavior. That's pretty clearly a CVS legacy, and it's rooted in the
idea that "you *must* be able to trust your local machine!!!!". This
remains blatantly false in these days of NFS shared home directories,
backup tapes, data center installed hosts managed by cage monkeys,
stolen laptops and servers, and zombie hosts roaming local networks
(all of which I've had to deal with professionally).
Adding sophisticated encryption capabilities on the host side fixes
*nothing* as long as client behavior, especially default client
behavior, allows such password storage. Approaches such as SSL key
access for https://, or SSH key access for svn+ssh:// access, is
workable. But even svn+ssh:// access presents issues because it's
layered on top of a natively unsecurable svnserve daemon
implementation. And there just aren't graceful toolkits published for
managementn of SSL keys or SSH keys for Subversion.
In fact, I'm talking to a vendor about that deficit next week, and
trying to encourage them to implement such key management as part of
their security tool suite. Wish me luck on that conversation.
Received on 2011-01-08 02:41:21 CET