Encryption and SVN

[Black Pearl]

Until now, every developer has his code secured by using cryptographic containers (TrueCrypt).

We now want to use the advantages of a small network including SCC (Subversion).

What we could do, is check in/check out of the complete crypto-container. But that would not allow to have each single VI put under revision control individually.

What other options do we have? We have not yet any experience with the SVN process, but are planning the network structure including folder structure of the central server. Is there any encryption support by SVN? Does passwort protected VIs work with SVN (using Tags?)? How secure are password protected VIs anyhow?

Felix

[Justin Goeres]

QUOTE (Black Pearl @ Apr 12 2009, 05:08 AM)

Until now, every developer has his code secured by using cryptographic containers (TrueCrypt).

We now want to use the advantages of a small network including SCC (Subversion).

What we could do, is check in/check out of the complete crypto-container. But that would not allow to have each single VI put under revision control individually.

What other options do we have? We have not yet any experience with the SVN process, but are planning the network structure including folder structure of the central server. Is there any encryption support by SVN?

What security threat, specifically, is it that you're trying to prevent?

If you're trying to secure the network traffic between your SVN server and clients, your clients can talk to SVN via https. You can set it up to use password authentication (which your clients can cache so they don't have to enter the password on every update or commit), or SSL keys.

If you're worried about client security, like a laptop being stolen while it's got checked-out code on it, then keep the code in an encrypted area on the local drive (TrueCrypt, as you mentioned, would do this).

If you're worried about the SVN repository itself being secure, it depends a lot on what type of machine you're hosting the repository on. That having been said, the repository is just a database that's made up of lots of files, so I would think that whatever standard security measures you normally use on the host OS (permissions, good passwords, turning off unnecessary services, etc.) would be steps in the right direction.

Since you mentioned that you haven't worked with the SVN process yet, I'll also point out that the folder structure of your repository is defined inside the repository. The host computer knows nothing about what's in there. As far as the host is concerned, the repository is just a big collection of semi-random-looking data.

QUOTE

Does passwort protected VIs work with SVN (using Tags?)?

Password-protected VIs aren't related to (or affected by) SVN at all. The password protection is just a property of the VI file itself that only LabVIEW cares about. SVN sees it as just another file. That having been said, I can't imagine ever using password protection on VIs that are under active development within a team.

QUOTE

How secure are password protected VIs anyhow?

In general, password protected VIs are not secure for any reasonably rigorous definition of security, and if you really need to protect your code you will want to do more than just password protect it.

[Black Pearl]

At first many thanks for your fast response on easter sunday.

Our main issue is the security on the server side. Only those developers that are on a certain project should have access to the source code. And we would like not to completley relay on the OS permissions.

QUOTE (Justin Goeres @ Apr 12 2009, 03:43 PM)

If you're worried about the SVN repository itself being secure, it depends a lot on what type of machine you're hosting the repository on. That having been said, the repository is just a database that's made up of lots of files, so I would think that whatever standard security measures you normally use on the host OS (permissions, good passwords, turning off unnecessary services, etc.) would be steps in the right direction.

Since you mentioned that you haven't worked with the SVN process yet, I'll also point out that the folder structure of your repository is defined inside the repository. The host computer knows nothing about what's in there. As far as the host is concerned, the repository is just a big collection of semi-random-looking data.

Can you clarify that last sentence a bit? I understand it from a technical viewpoint, as the SVN keeps track of the changes in the directory structure and works incremental on binary level. But could not any one with a SVN client (given that the server is open to them) check out all files, or is the repository password protected?

Felix

[LAVA 1.0 Content]

QUOTE (Black Pearl @ Apr 14 2009, 09:16 AM)

... But could not any one with a SVN client (given that the server is open to them) check out all files, or is the repository password protected?

It is good to define access here. I think you mean a physical access via TCP/IP.

You can close a SVN repository for any kind of anonymous access, or make the anonymous (or unknown) clients read-only.

Clients/Users can be password protected

Ton

[Mellroth]

QUOTE (Black Pearl @ Apr 14 2009, 09:16 AM)

But could not any one with a SVN client (given that the server is open to them) check out all files, or is the repository password protected?

It is possible to configure the SVN server to only accept users in a domain to access the server.

Then you can restrict each repository on the server to only allow access for a subset of these domain users.

It is also possible to set permissions (by adding hooks), for a repository so that only a few users can add data to the /tags hierarchy, while granting "read access only" for all other users.

/J

[cristian]

QUOTE (JFM @ Apr 14 2009, 09:23 AM)

It is also possible to set permissions (by adding hooks), for a repository so that only a few users can add data to the /tags hierarchy, while granting "read access only" for all other users.

/J

Its also possible, by using client side hooks, to encrypt files before submiting them to SVN repository and decrypt them at checkout. Check http://sourceforge.net/projects/cryptohook/

[Shaun Hayward]

We use a really simple svn server (that is still free) called VisualSVN. It allows us to specify permissions on a per folder level (it may even allow per file... I cant remember) and supports Active Directory and groups etc (so we can, for example allow all Programmers read-only access, all managers read-write access, and individual developers read-write as needed). Then, for network transport it uses https so that's encryped and finally, it uses the same usernames and passwords as everything else so our developers dont have to try and remember even more passwords.

With this approach the actual data is not accessible directly - it is kept on the server and only the user account that the VisualSVN application (and local/domain administrators) can actually write to the data.

It works with all standard svn clients (although they do sell one targeteted at Visual Studio guys) as it is basically Subversion, Apache, a few bells and whistles tied together with a friendly GUI.

http://www.visualsvn.com/server

Shaun

[jdunham]

QUOTE (Black Pearl @ Apr 14 2009, 12:16 AM)

Our main issue is the security on the server side. Only those developers that are on a certain project should have access to the source code. And we would like not to completley relay on the OS permissions.

There are lots of good suggestions here, but if you care about server security, you would be *crazy* not to run SVN over https://. Many, many engineers have devoted huge efforts in making https reasonably secure (if administered properly) and no other hack you can do yourself is going to be as effective or have as much engineering and reliability behind it.

Start with https, and if that's not secure enough (using TrueCrypt for your working copies may be advisable too) then you can either ask here or on many of the internets security forums for more advice.

[Black Pearl]

Thanks to all for your help.

From the discussion so far, on the server side we can't work with encryption but rely on access permissions. The other points (https, client side encryption) are clear.

We will discuss the issues today and I might come back with some more questions.

Felix