[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Encrypting selected files ...

From: Parrish, Ken <KParrish_at_gomez.com>
Date: Fri, 2 Oct 2009 13:48:02 -0400

Thank you to all for your helpful suggestions. I very much agree that this is primarily a company policy, process and work flow issue. My colleagues agree with me that no solution is a solution until we establish a clear policy and methodology for how and where to secure this data, and to whom and how access is granted.

Fundamentally, production access control data simply should not exist in our primary source code directories in our repository. I was hoping to gather the ideas and experience of others with similar problems, and have certainly received good feedback.

Generally, our source tree contains resource access information for QA and test assets, not production assets, however there are exceptions. I think we need to weed out and delete the exceptions first, then either establish an encryption mechanism, or a separate portion of the repository with highly restricted access, or both.

Thank you all for your input. As always, I find the feedback on this users list very thoughtful and extremely helpful.

Ken Parrish
Gomez, Inc.

-----Original Message-----
From: Pat Farrell [mailto:pfarrell_at_pfarrell.com]
Sent: Friday, October 02, 2009 12:08 PM
To: users_at_subversion.tigris.org
Subject: Re: Encrypting selected files ...

Les Mikesell wrote:
>> Its simple. put those things in a properties file or equivalent and do
>> not use SVN for them.
> That's correct in theory, but I'd bet that most places that keep any
> production code/configurations in subversion have this issue.

All places that use this approach have no security.

This is a fundamental issue, don't do that.

> There are just too many places where you can't separate them.

If you care, at all, about security, you must separate them.

I will agree that too many places put these in SVN, or equivalent, but
that does not make it acceptable. Its simply poor operational design.

Most theft and fraud are inside jobs. You can not allow simple access to
the source code to allow access to production.

This does not prevent the operations folks from having their own SVN
inside their security perimeter. But its simply wrong to put production
passwords in the general engineering SVN.

Pat Farrell
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-02 19:49:02 CEST

This is an archived mail posted to the Subversion Users mailing list.