Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm trying to understand if security is a real concern, or if distribution actually does a better job with security. See, the access to the main source repository could be layered and inherently managed by a network of trust, and could still have centralized user management integrating users from an LDAP/Active Directory, while the centralized version control system just relies on the later. With distribution, access could even be given to less users per repository in different countries and maintained easier.

I can see why it is easy to think that having tight & centralized access management to a code repository translates to security, however, that doesn't mean that code cannot be accessed or redistributed other ways. But, is there a real argument/use case/scenario for security where the centralized model is just better than the distributed one?.

Some context: I'm trying to make the case (with a whitepaper) to my company to switch to a DVCS (I already have other problems identified that are successfully addressed by most DVCSs) and security is one of the arguments I'm expecting to have to justify. My company is open minded though; they currently use perforce and are distributed geographically.

share|improve this question
add comment

2 Answers

up vote 6 down vote accepted

On the contrary, a DCVS can be far more secure, and here is why:

Whereas a given developer having source code in any form on their workstation can do anything they want to do (steal it, share it, post it to facebook), you have to address that issue outside of version control. So it's the same playing field once a working copy is checked out.

When it comes to checking out a working copy, I would imagine the security is comparable. We use SSH for all access to git, so it is about as secure as it gits (pun intended).

Here is where they are different:

If you use the proper workflow, then nobody but your most trusted engineers have push access to your primary repository. Regular developers work...work...work, and then submit a pull request to the trusted engineer, who will pull, review, and push to the main repository.

Think how open source projects, like Linux, manage their workflow in a no-trust environment. If the same concepts are applied to your DCVS workflow, you actually have far better security with regards to bugs, security holes, or malicious code being added to your product.

share|improve this answer
add comment

There are two aspects to security: reading and writing. If you have read permissions on centralized source control, you have enough permissions to convert it to a DVCS repo no one else knows about. Therefore, security from unauthorized distribution is a wash either way.

While in theory CVCS has robust and fine-grained permission controls on what can get written into the repository, the reality is these permissions become ever looser as people need to get their job done. Once granted "temporarily," permission is rarely ever taken away.

The distributed nature of DVCS means people have the power to do whatever they need in their local repo, making it easier for others to strictly control what goes into the official repo. PQ can control a repo that nothing goes into unless it passes their tests, while developers have free reign over their own domain. For example, this structure allows Linus Torvalds to personally approve every single change that goes into the Linux kernel, although a lot of those changes he approves by virtue of his trust of his lieutenants.

In other words, DVCS security is like guarding individual jail cells, where CVCS security is like guarding an exercise yard. The smaller the number of people who have access, the easier it is to control.

share|improve this answer
    
Worth noting is the fact that, for example, in git you only need hash for a single commit and have a verifiable history for the whole project up to that point. It suddenly makes it very easy to verify that the history has not been modified. Also, this allows e.g. testers to add signed tags to the revisions that have been tested or certified. –  Mikko Rantalainen May 7 '12 at 12:15
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.