You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Parrish, Ken" <KP...@gomez.com> on 2009/10/02 14:56:15 UTC
Encrypting selected files ...
I have been asked to look into the issue of encrypting sensitive information that is stored in our source code repository. We have quite a few users of our repository, many of whom are overseas.
99.99% of what's in our repository is just source code that everyone needs. However there are a few files that contain production usernames, passwords and other references to assets that we would like to encrypt and allow access only to selected users or those with an encryption key.
I know that we can restrict access on a directory by directory basis and this option is being considered. However, I'd prefer to allow these files to be comingled with other source code files.
Are there any facilities in Subversion for encrypting individual files?
If not, does anyone have any recommendations for tools that might be effective for encrypting individual files?
Is it possible to implement some sort of 'hook' in subversion that can be instructed to encrypt / decrypt selected files for selected users?
Thoughts, idea on this topic?
Ken Parrish
Gomez, Inc.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2402959
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Aaron Turner <sy...@gmail.com>.
On Fri, Oct 2, 2009 at 7:56 AM, Parrish, Ken <KP...@gomez.com> wrote:
> I have been asked to look into the issue of encrypting sensitive information
> that is stored in our source code repository. We have quite a few users of
> our repository, many of whom are overseas.
>
> 99.99% of what’s in our repository is just source code that everyone needs.
> However there are a few files that contain production usernames, passwords
> and other references to assets that we would like to encrypt and allow
> access only to selected users or those with an encryption key.
Since you're trying to secure files from certain developers I see three options:
1. Use PGP/GnuPG to encrypt them.
2. Move these sensitive files to a location in your source tree where
you can deny read permission to them via SVN's built in access
controls.
3. Use property files, ENV vars, etc to set these sensitive values and
only tell them to those who need to know.
> Are there any facilities in Subversion for encrypting individual files?
No. SVN has no encryption other then SSL for secure file transfer.
> If not, does anyone have any recommendations for tools that might be
> effective for encrypting individual files?
PGP/GnuPG. You don't have to use PGP keys if you don't want to.
PGP/GnuPG supports "symmetric key encryption" like AES where the same
password is used to encrypt and decrypt the file.
> Is it possible to implement some sort of ‘hook’ in subversion that can be
> instructed to encrypt / decrypt selected files for selected users?
Hooks are on the server, not client and hence not possible.
> Thoughts, idea on this topic?
In general, your design (putting production passwords in your source
tree) is flawed from a pure security standpoint and not in line with
best practices. It is not recommended.
--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
-- Benjamin Franklin
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2402985
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Pat Farrell <pf...@pfarrell.com>.
Andrey Repin wrote:
> I do have similar issue. To solve it, i have separate, non-versioned
file with
> all credentials written in it, that project picks up.
> This is also true for deployment. User get a
"config-auth-example.php", copy
> it over to "config-auth.php" and adjust for his/her needs.
> Now you're 1001% sure you will never ever overwrite the user settings
with any
> upgrades. Simply because redistribution does not contain this file.
I so similar stuff with my Java code. The connection properties are read
from a standard Java Properties file. And test values are stored under
"testing" for JUnit to use. Plus, there is an environment variable that
developers can use to point to their own values, containing whatever
they want.
"redistribution does not contain this file" is the right answer.
--
Pat Farrell
http://www.pfarrell.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403038
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, Parrish, Ken!
> I have been asked to look into the issue of encrypting sensitive information
> that is stored in our source code repository. We have quite a few users of
> our repository, many of whom are overseas.
Sensitive information must not be stored in open repository.
Establish separate, properly secured repository for this task.
> 99.99% of what's in our repository is just source code that everyone needs.
> However there are a few files that contain production usernames, passwords
> and other references to assets that we would like to encrypt and allow
> access only to selected users or those with an encryption key.
I do have similar issue. To solve it, i have separate, non-versioned file with
all credentials written in it, that project picks up.
This is also true for deployment. User get a "config-auth-example.php", copy
it over to "config-auth.php" and adjust for his/her needs.
Now you're 1001% sure you will never ever overwrite the user settings with any
upgrades. Simply because redistribution does not contain this file.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 02.10.2009, <22:39>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403032
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Encrypting selected files ...
Posted by Bob Archer <bo...@amsi.com>.
>I have been asked to look into the issue of encrypting sensitive information that is stored in our source code repository. We have quite a few users >of our repository, many of whom are overseas.
>99.99% of what's in our repository is just source code that everyone needs. However there are a few files that contain production usernames, >passwords and other references to assets that we would like to encrypt and allow access only to selected users or those with an encryption key.
>I know that we can restrict access on a directory by directory basis and this option is being considered. However, I'd prefer to allow these files to >be comingled with other source code files.
>Are there any facilities in Subversion for encrypting individual files?
>
>If not, does anyone have any recommendations for tools that might be effective for encrypting individual files?
>
>Is it possible to implement some sort of 'hook' in subversion that can be instructed to encrypt / decrypt selected files for selected users?
>
>Thoughts, idea on this topic?
Just thinking out loud... this is something that will have to be done on the client side... the file will have to be encrypted before it is committed. This will also mean that the file is basically a binary file and you can't merge or blame or diff it.
That said, I think you could use PGP or CompuSec (both free) for this. But, now rather than controlling access to the file, you have to control access to the private key which would be needed to decrypt it.
So, I'm not sure if you are solving a problem or just moving the problem to a different file in addition to adding overheard to your process. It may just make more sense to secure access to the file with sensitive data itself rather than worry about securing access to a private key.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2402968
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Alec Kloss <al...@oracle.com>.
On 2009-10-02 13:57, Les Mikesell wrote:
> Alec Kloss wrote:
> > On 2009-10-02 14:08, Bob Archer wrote:
> > [chop]
> >> Some of this stuff also depends on what you are storing. Perhaps going another way would be better. For example, use NT Authentication to access your SQL servers rather than username/password. This way, the password isn't in the configuration file. I am sure there are similar LDAP type ways to deal with this for other technologies also.
> >>
> > [chop]
> >
> > Seconded. Passwords for services are a relic from the 80s.
> > Buildbots and so on should have a collection of keys that are used
> > to build things. Between GSSAPI, NTLM, PKI, and ssh public keys,
> > there shouldn't be too many technologies left that need a
> > clear-text password. Your source-controlled configuration files
> > should tell you which accounts should do what and you should have
> > encryption keys on the side accessable only by the accounts that
> > need them, and a rotation policy in place to ensure you don't find
> > yourself using a 512 bit PKI key you generated 10 years ago.
>
> OK, so how do you connect an assortment of perl/java/php services to an
> assortment of mysql/postgresql/sql server databases without something in
> the configurations that would be reusable if you can get a copy?
>
I'm more of a Kerberos than PKI/SSL guy, but the concepts are
essentially the same. You configure whatever unix account is going
to be running these services with access to some sort of encryption
key. Let's call this account "webapp". You use the OS itself
to harden access to the key so only webapp can access it. In
Kerberos, this would normally be a "keytab" and in PKI, it's a
PKI private key (plus associated certificates). This key is the
only thing you omit from your configuration change control. You
then configure each application that will be run by the webapp
service to know that it can use this key to authenticate to any
external resources it needs, like a RDBMS, Subversion, and so on.
It's clear in the event of a disaster recovery that the only thing
that needs to be regenerated is this encryption key. All other
information, like which key to use, is all change controlled.
As for the specific software you mention, I'm sure there's a lot of
variety in capilities. Postgresql definitely supports Kerberos and
I suspect also supports PKI, MSSQL probably supports both too, and
almost definitely supports Kerberos. I don't really know about
mysql. As for clients, I suspect since perl usually wraps the
native client libraries for things, it'll support anything the
servers will. Java is usually bad at this, as people like to
rewrite client drivers in Java without fully implementing the
server protocol. I'm not much a PHP user, so I can't say about it.
Worst case, since all of these use a TCP socket to communicate with
a server, you can use a third-party tool like stunnel or plain old
SSH tunnels to create authenticated tunnels between the machine
that webapp is running services on and the servers it needs to
connect to. This is a substantial pain, but can be done.
--
Alec.Kloss@oracle.com Oracle Middleware
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x432B9956
Re: Encrypting selected files ...
Posted by Les Mikesell <le...@gmail.com>.
Alec Kloss wrote:
> On 2009-10-02 14:08, Bob Archer wrote:
> [chop]
>> Some of this stuff also depends on what you are storing. Perhaps going another way would be better. For example, use NT Authentication to access your SQL servers rather than username/password. This way, the password isn't in the configuration file. I am sure there are similar LDAP type ways to deal with this for other technologies also.
>>
> [chop]
>
> Seconded. Passwords for services are a relic from the 80s.
> Buildbots and so on should have a collection of keys that are used
> to build things. Between GSSAPI, NTLM, PKI, and ssh public keys,
> there shouldn't be too many technologies left that need a
> clear-text password. Your source-controlled configuration files
> should tell you which accounts should do what and you should have
> encryption keys on the side accessable only by the accounts that
> need them, and a rotation policy in place to ensure you don't find
> yourself using a 512 bit PKI key you generated 10 years ago.
OK, so how do you connect an assortment of perl/java/php services to an
assortment of mysql/postgresql/sql server databases without something in
the configurations that would be reusable if you can get a copy?
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403039
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Pat Farrell <pf...@pfarrell.com>.
Alec Kloss wrote:
> Storing only encrypted source in the source control system prevents
> your system administrators from being able to read the source. I
> can see value in that.
I can not see any value in that. At some point, you have to trust some
of your employees.
If you don't trust your sysadmins, what is keeping them from installing
key loggers on your PC?
Seeing the source is not an issue with security, in fact, good security
relies upon known algorithms with open source code. All of the security
is in the keys.
Nothing else.
The idea of using Security By Obscurity for source code strikes me as
terrible software engineering.
When I worked at a pioneering Internet commerce company, which was
completely SAS-90 compliant, etc. we defined that security meant that
our engineers, who were in our office and on our LAN, with complete
access to all of the source code, could not do anything bad.
Its the same as the issue of encrypting all of your data in an RDMBS,
the data base administrator sure has to be able to see the data, its
part of their job.
--
Pat Farrell
http://www.pfarrell.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403125
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Alec Kloss <al...@oracle.com>.
On 2009-10-02 16:42, Pat Farrell wrote:
> Alec Kloss wrote:
> > I'd be curious to know if someone has thoughts on
> > how to add client-side support for PGP encrypting files prior to
> > committing them to Subversion.
>
> I can't think of a way that this would be useful, assuming that you have
> multiple developers using the repository.
>
> Each user has to have read and write access to be able to do anything
> useful.
>
> If you share the PGP/GPG private key, then it is no longer private.
>
> Plus, I don't want source code treated as blobs, you lose the ability to
> do diffs between versions, etc. which are critical for any useful
> version control system.
>
> > For those of us who
> > work on commercial software, it would be attractive to have all
> > source encrypted on disk at all times, including when it's in a
> > source repository, and such a feature would be an interesting
> > feature for Subversion.
>
> I can't see any value in this "keep it all encrypted" idea, but there
> are many ways to have encrypted volumes in nearly all operating systems,
> just use one and be happy.
>
> Most of the time, encrypted files are used only for data either in
> transit or in long term storage.
>
> Adding encryption to SVN is the worst kind of feature bloat. Do one
> thing, do it well, let the OS or filesystem handle your needs for file
> encipherment.
Storing only encrypted source in the source control system prevents
your system administrators from being able to read the source. I
can see value in that. The problem with multiple consumers of the
same encrypted data is already addressed by PGP. I don't see any
reason why this can't be done; after some thought, the idea of
doing it in a wrapper around your svn tool probably won't work well
for some operations, like svn diff especially, but there's no
reason the svn clients couldn't understand that some source files
are encrypted and, when creating a diff, decrypt the pertinent
versions and then present a diff of the cleartext. Obviously diffs
of cyphertext are of limited value.
--
Alec.Kloss@oracle.com Oracle Middleware
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x432B9956
Re: Encrypting selected files ...
Posted by Pat Farrell <pf...@pfarrell.com>.
Alec Kloss wrote:
> I'd be curious to know if someone has thoughts on
> how to add client-side support for PGP encrypting files prior to
> committing them to Subversion.
I can't think of a way that this would be useful, assuming that you have
multiple developers using the repository.
Each user has to have read and write access to be able to do anything
useful.
If you share the PGP/GPG private key, then it is no longer private.
Plus, I don't want source code treated as blobs, you lose the ability to
do diffs between versions, etc. which are critical for any useful
version control system.
> For those of us who
> work on commercial software, it would be attractive to have all
> source encrypted on disk at all times, including when it's in a
> source repository, and such a feature would be an interesting
> feature for Subversion.
I can't see any value in this "keep it all encrypted" idea, but there
are many ways to have encrypted volumes in nearly all operating systems,
just use one and be happy.
Most of the time, encrypted files are used only for data either in
transit or in long term storage.
Adding encryption to SVN is the worst kind of feature bloat. Do one
thing, do it well, let the OS or filesystem handle your needs for file
encipherment.
--
Pat Farrell
http://www.pfarrell.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403083
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Alec Kloss <al...@oracle.com>.
On 2009-10-02 14:08, Bob Archer wrote:
[chop]
>
> Some of this stuff also depends on what you are storing. Perhaps going another way would be better. For example, use NT Authentication to access your SQL servers rather than username/password. This way, the password isn't in the configuration file. I am sure there are similar LDAP type ways to deal with this for other technologies also.
>
[chop]
Seconded. Passwords for services are a relic from the 80s.
Buildbots and so on should have a collection of keys that are used
to build things. Between GSSAPI, NTLM, PKI, and ssh public keys,
there shouldn't be too many technologies left that need a
clear-text password. Your source-controlled configuration files
should tell you which accounts should do what and you should have
encryption keys on the side accessable only by the accounts that
need them, and a rotation policy in place to ensure you don't find
yourself using a 512 bit PKI key you generated 10 years ago.
Unfortunately, we've all been talking about how you shouldn't put
sensitive information into Subversion because we've been assuming
it's passwords. I'd be curious to know if someone has thoughts on
how to add client-side support for PGP encrypting files prior to
committing them to Subversion. I imagine a giant enhancement to my
current svn wrapper script to look at properties to determine key
lists for encrypting a file as I commit it. For those of us who
work on commercial software, it would be attractive to have all
source encrypted on disk at all times, including when it's in a
source repository, and such a feature would be an interesting
feature for Subversion.
--
Alec.Kloss@oracle.com Oracle Middleware
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x432B9956
Re: Encrypting selected files ...
Posted by Pat Farrell <pf...@pfarrell.com>.
Bob Archer wrote:
> Some of this stuff also depends on what you are storing. Perhaps
> going another way would be better. For example, use NT Authentication
> to access your SQL servers rather than username/password. This way,
> the password isn't in the configuration file. I am sure there are
> similar LDAP type ways to deal with this for other technologies also.
Yes, LDAP or Kerberos or SSH or anything, but do *not* store passwords
in the source code SVN.
--
Pat Farrell
http://www.pfarrell.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403035
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Encrypting selected files ...
Posted by Bob Archer <bo...@amsi.com>.
> Les Mikesell wrote:
> > But if you care about version control, you must include the parts of
> > code/configuration involved in your repository.
>
> No, you put development versions of the configuration in the
> developer's
> SVN. Not operations. And you have ways to override stuff.
>
> > They are often need to be included in a file of code or configuration
> > that is someone else's design. Bad design or not
>
> Its a very bad design. Again, if you care about security, you have no
> choice.
>
> >> Most theft and fraud are inside jobs. You can not allow simple
> access to
> >> the source code to allow access to production.
> >
> > Nor is it a good idea to put things into production that aren't under
> > version control.
>
> I did not say use nothing on the production side.
>
> What I said was that developers have zero access to the production
> configuration. They have access to the developement and/or testing
> configuration
>
> Ops can have their own SVN, but no access from the development
> engineers
>
>
> >> 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.
> >
> > So how do you roll out code/configurations to a bunch of machines
> with
> > the ability to roll back without storing it somewhere that the people
> > who develop/test it can access?
>
> You seem to be thinking that development engineers are allowed to touch
> production. That is not how secure or even well run sites are operated.
Some of this stuff also depends on what you are storing. Perhaps going another way would be better. For example, use NT Authentication to access your SQL servers rather than username/password. This way, the password isn't in the configuration file. I am sure there are similar LDAP type ways to deal with this for other technologies also.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403027
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, Les Mikesell!
>>> So how do you roll out code/configurations to a bunch of machines with
>>> the ability to roll back without storing it somewhere that the people
>>> who develop/test it can access?
>>
>> You seem to be thinking that development engineers are allowed to touch
>> production. That is not how secure or even well run sites are operated.
> No, I'm thinking that development engineers develop the configurations
> that have to be tested and then deployed to production, and also the
> processes to do the deployment, because ummm, they're the ones that do
> development. And the operations people that manage the production
> servers need to be able to roll versions forward or backwards with fully
> tested configurations. So you either put complete configs under version
> control or you have operators making changes on the fly that can't be
> tested.
Access credentials =/= project configuration.
You can maintain configuration in a project tree, although i wouldn't
recommend this, but access credentials is just too sensitive to be so careless
about them.
Two things that I can come up with, is
1. Access credentials has no impact on project, other than allowing or denying
it from operating. They can be either right or wrong, you do not really need
to track their changes.
2. It does not change often, in the meaning that you need some SERIOUS reason
to change source URI... i.e. actual deployment of a project, to connect it to
production database.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 02.10.2009, <22:46>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403037
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Pat Farrell <pf...@pfarrell.com>.
Les Mikesell wrote:
>> I am not saying no version control for operational configurations. What
>> I am saying is that the developers get ZERO access to those
>> configurations.
>
> Yet you don't mention the mechanism in subversion to accomplish this.
Its not a SVN issue. The developers have one repository, the ops guys
another. They don't talk to each other, one can not see the other.
> which is why I think there should be a generic way to handle this general problem.
Its not a development problem. There can be no general solution to this
problem.
You are asking in the wrong list about the wrong problem.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403048
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Les Mikesell <le...@gmail.com>.
Pat Farrell wrote:
> Les Mikesell wrote:
>> So you either put complete configs under version
>> control or you have operators making changes on the fly that can't be
>> tested.
>
> You are not reading my replies carefully.
I'm reading them. I just don't find an answer there.
> I am not saying no version control for operational configurations. What
> I am saying is that the developers get ZERO access to those configurations.
Yet you don't mention the mechanism in subversion to accomplish this.
> If you care about security, you have to do it some other way. SSH,
> separate SVN repositories, manual entry, etc. are all possible.
>
> Its an operations procedure question.
Just more things to go wrong if you have special cases. We actually do,
and yes, they have gone wrong (like tests passing with test credentials
that failed in the production setup), which is why I think there should
be a generic way to handle this general problem.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403046
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Pat Farrell <pf...@pfarrell.com>.
Les Mikesell wrote:
> So you either put complete configs under version
> control or you have operators making changes on the fly that can't be
> tested.
You are not reading my replies carefully.
I am not saying no version control for operational configurations. What
I am saying is that the developers get ZERO access to those configurations.
If you care about security, you have to do it some other way. SSH,
separate SVN repositories, manual entry, etc. are all possible.
Its an operations procedure question.
Pat
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403034
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Les Mikesell <le...@gmail.com>.
Pat Farrell wrote:
>> So how do you roll out code/configurations to a bunch of machines with
>> the ability to roll back without storing it somewhere that the people
>> who develop/test it can access?
>
> You seem to be thinking that development engineers are allowed to touch
> production. That is not how secure or even well run sites are operated.
No, I'm thinking that development engineers develop the configurations
that have to be tested and then deployed to production, and also the
processes to do the deployment, because ummm, they're the ones that do
development. And the operations people that manage the production
servers need to be able to roll versions forward or backwards with fully
tested configurations. So you either put complete configs under version
control or you have operators making changes on the fly that can't be
tested.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403024
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Pat Farrell <pf...@pfarrell.com>.
Les Mikesell wrote:
> But if you care about version control, you must include the parts of
> code/configuration involved in your repository.
No, you put development versions of the configuration in the developer's
SVN. Not operations. And you have ways to override stuff.
> They are often need to be included in a file of code or configuration
> that is someone else's design. Bad design or not
Its a very bad design. Again, if you care about security, you have no
choice.
>> Most theft and fraud are inside jobs. You can not allow simple access to
>> the source code to allow access to production.
>
> Nor is it a good idea to put things into production that aren't under
> version control.
I did not say use nothing on the production side.
What I said was that developers have zero access to the production
configuration. They have access to the developement and/or testing
configuration
Ops can have their own SVN, but no access from the development engineers
>> 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.
>
> So how do you roll out code/configurations to a bunch of machines with
> the ability to roll back without storing it somewhere that the people
> who develop/test it can access?
You seem to be thinking that development engineers are allowed to touch
production. That is not how secure or even well run sites are operated.
--
Pat Farrell
http://www.pfarrell.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403012
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Les Mikesell <le...@gmail.com>.
Pat Farrell wrote:
> 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.
But if you care about version control, you must include the parts of
code/configuration involved in your repository.
> 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.
They are often need to be included in a file of code or configuration
that is someone else's design. Bad design or not, pretty much every
front-end service that needs access to a backend database has a
configuration file that you need to maintain that has the credentials
embedded.
> Most theft and fraud are inside jobs. You can not allow simple access to
> the source code to allow access to production.
Nor is it a good idea to put things into production that aren't under
version control.
> 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.
So how do you roll out code/configurations to a bunch of machines with
the ability to roll back without storing it somewhere that the people
who develop/test it can access?
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403003
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Encrypting selected files ...
Posted by "Parrish, Ken" <KP...@gomez.com>.
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@pfarrell.com]
Sent: Friday, October 02, 2009 12:08 PM
To: users@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
http://www.pfarrell.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2402982
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403021
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Pat Farrell <pf...@pfarrell.com>.
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
http://www.pfarrell.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2402982
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Les Mikesell <le...@gmail.com>.
Pat Farrell wrote:
> Parrish, Ken wrote:
>> 99.99% of what’s in our repository is just source code that everyone
>> needs. However there are a few files that contain production usernames,
>> passwords and other references to assets that we would like to encrypt
>> and allow access only to selected users or those with an encryption key.
>
> Its simple. put those things in a properties file or equivalent and do
> not use SVN for them.
>
> Your problem is more fundamental than whether or not SVN can do the
> specific things you want, rather, you should not want to do what you are
> thinking about.
>
> Keeping production server secrets is a separate topic.
That's correct in theory, but I'd bet that most places that keep any
production code/configurations in subversion have this issue. That is,
they either include things like the backend database credententials in
their version-controlled configurations when they shouldn't, or they
don't version-control the configurations or management scripts at all
when they should. There are just too many places where you can't
separate them.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2402979
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Encrypting selected files ...
Posted by Pat Farrell <pf...@pfarrell.com>.
Parrish, Ken wrote:
> 99.99% of what’s in our repository is just source code that everyone
> needs. However there are a few files that contain production usernames,
> passwords and other references to assets that we would like to encrypt
> and allow access only to selected users or those with an encryption key.
Its simple. put those things in a properties file or equivalent and do
not use SVN for them.
Your problem is more fundamental than whether or not SVN can do the
specific things you want, rather, you should not want to do what you are
thinking about.
Keeping production server secrets is a separate topic.
--
Pat Farrell
http://www.pfarrell.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2402971
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].