views:

230

answers:

5

Do any version control systems allow you to specify line level security restrictions rather than file level? I know it would be horrible to maintain. If I wanted to never allow certain strings into the database should I be looking into the notion of hooks and manage all the very sensitive information in that hook layer? How do hooks get replicated from system to system?

Update: Maybe the best way to manage this is to pgp encrypt the sensitive data and those who cannot decrypt it will be left in the dark. Any thoughts on that? Probably not a best practice from a security standpoint.

+1  A: 

Subversion doesn't allow it, and I don't think any others do.

Osama ALASSIRY
+2  A: 

Perhaps you should separate out the worrisome strings, lines, and functions into a separate file (or better yet files). That way you can just manage the file(s) in question.

C. Ross
I tend to agree but as version control systems go viral and distributed this management becomes a bit of an abortion.
ojblass
I'm not sure I know what you mean by "an abortion". Also how are Version Control systems going viral?
C. Ross
I'm guessing its the eggcorn: abberation/abortion
Cheekysoft
+1  A: 

You could run separate repositories and maintain stricter controls on the repository with the sensitive data.

kbyrd
as repositories go distributed I have trouble understanding what is exactly under my control. My choice of subversion was actually partially due to the fact that it is more centralized. Breaking it into another repository is likely the best option I have. I was thinking maybe pgp encrypt the sensitive information and allow it out wherever it needs to go.
ojblass
+3  A: 

We had the same problem and decided to solve it by setting up a second repository.

This originated when I needed to store our configuration management files in version control, which contained sensitive information. It made sense to store the sensitive data from our applications in there as well.

We originally used svn externals and git submodules to include the sensitive data, but later found it less troublesome to just simlink to another location.

I also find it helpful to add the proper ignores to prevent the same files ever getting checked in to the development repository. Since doing this we have not had anyone accidentally check in anything sensitive.

It helps try an keep the sensitive information contained in a concise set of config files -- I would not spread it out, put it one place and guard that place.

csexton
The ignrore option is truly a great tip thank you.
ojblass
Great answer. It steps back from the OP's target of a solution to address the real concern, and offers an alternative.Actual question seems to relate more to control over different sets of data and allowing those into/out of certain repositories.Going further though, if you're required to version control sensitive information, then there should be a properly protected repository to allow this. Then you have one repository where you ignore the sensitive data (the development/public one), and one where you can push your changes of sensitive data.
maxwellb
+2  A: 

Do any version control systems allow you to specify line level security restrictions rather than file level?

Does any Operating System allow you to specify line level security restrictions rather than file level? Probably only at the NSA (and friends).

You're best bet is to encrypt any file containing sensitive information before adding it to version control. This also protects it from accidental display, e.g. git diff while someone is looking over your shoulder.

pgs