0

My company works with different developers from different studios, always sharing the code to everyone aboard. At the moment, we need to protect a part of the code, not from theft but from some random developer in the studio maybe changing something important by mistake. Is there a way to protect a critical part of the code from this happening?

  • 7
    That's what versions control systems are for. Do you review pull requests before accepting them? Do your other parties produce commits that are too full of meaningless noise and churn to tell what meaningful changes they are making? Do they regularly touch files outside of their assigned parts of the project? – Chris Stratton Mar 8 at 15:53
  • @ChrisStratton - Your comment is the start of a good answer. – Dan Pichelman Mar 8 at 15:56
  • 1
    Can you separate the code into a different repository, and do something with access rights? – Erik Schot Mar 8 at 15:58
  • 8
    Which VCS are you using? – Doc Brown Mar 8 at 16:00
  • 1
    @Flater access rules can protect against direct commits to master or those by the wrong party. But deciding what will be approved is always ultimately manual. – Chris Stratton Apr 4 at 23:11
3

You need some mechanism that prevents developers from changing parts of the code they shouldn't be changing, at least not without review. This means that you will have to integrate your version control server with some access control or code review system.

Git in particular has no built-in access control model and a fairly weak security model (it is easy to fake a commit that looks like it was created by a colleague). That means you need an external system.

Such a system could be implemented using server-side hooks that for example check whether the commits are authentic (e.g. you could enforce that commits must be signed) and the hooks could reject a push if code outside of that developer's authorization was changed. Such hooks could also enforce that the code was first reviewed by a different person.

GitHub in particular already implements various mechanisms to that effect.

  • Branches can be marked as protected, so that no one (or only admins) can push directly to that branch. All others must first create a pull request for their changes, and someone with write access to the GitHub repository must approve the pull request before it will be merged.

  • You can create a CODEOWNERS file which associates file patterns with groups of reviewers. These people will be automatically alerted when a pull request touches the code they own. This helps to keep code reviews useful for larger repositories.

    See also the announcement on the GitHub blog. The system was inspired by the review system used for the Chromium project.

A completely different yet similar approach is the Lieutenant model used by the Linux Kernel. Everyone can change anything in their own repositories, as is normal with Git. But these changes will not generally become part of the official release. Instead, developers have to ask a Lieutenant to include their changes in their repository, until the changes bubble up to the official repository. At each level, reviewers sign off on the commits to ensure they are OK. The effect is similar to the CODEOWNERS approach, though less centralized and more reliant on personal trust.

Git as a distributed version control system is more flexible and less restrictive by design than centralized systems. More enterprisey centralized systems such as Perforce do feature a detailed access control model, for example preventing access to some directories and branches, or only allowing read access. Such approaches are especially valuable when developers aren't trusted, for example when you need to hire consultants for a tiny module of your Top Secret World Domination Project.

  • 1
    GitHub may not be the best choice for someone whose question starts with "My company ..." – David Hammen Mar 8 at 23:26
  • 2
    @DavidHammen So? GitHub isn't just for Open Source, they also have business offerings, including an Enterprise edition that can be installed on premises. The mentioned CODEOWNERS functionality is available for public repos and for all paid tiers. I'm sure their competitors like Bitbucket or Gitlab have comparable functionality, I'm just not as familiar with those. – amon Mar 8 at 23:32
  • Bitbucket's Codeowner – Laiv Apr 5 at 18:19
2

I just want to suggest a simple solution for specific case.

always sharing the code to everyone aboard is meaning you are using Source Control like TFS for me. If it is correct, I can suggest an easy way to you with one assumption:

If different developers from different studios are responsible for separate module(s)(class library), but all modules work with together, then you can authorize each studio for their own module(s) on Source Control and publish all modules latest build version on a server. By doing this, each studio can reach their own source code from Source Control and can add required DLLs from that server. So, no one can change another studio codes.

0

As others have already mentioned, Git(hub) doesn't really have a deep access control mechanism, so you can't just lock files based on user access rights (afaik). Other VCSes might do this, but companies tend not to want to change their VCS willy nilly.

With Git, you'd be stuck doing manual code review in order to detect changes in files you don't want changed. Hopwever, I don't consider this a good enough solution, as it still leaves the door open to human error.


If you don't want a developer to touch the source code, don't give them the option to update the source code. You could, for example, provide them with the DLL and documentation. That documentation could even be in the form of a copy of the source code (with no way of committing changes, just a simple file copy with no Git access).

Whenever my company has subcontracted work (part of a project, rather than a whole project), we have exposed our source material using an (on-our-premise) Nuget repository so the subcontractors have access to, but cannot change, the actual source material.
You don't need Nuget for this. Any method of transferring a DLL to the studio would do (email, FTP, ...). But Nuget (among others) makes it easier to handle versioning in case you update your source code (e.g. while the studio is mid-development).

Depending on the studio, they can either have their own Git repository which they check in and you have accesss to; or they could decide to not give you access to their source code either, and in that case they simply return their own dll to you. The difference here depends on the contract between your company and the subcontractor, and who owns the studio's source code that is created for this project.

In either case, you can then run the end product using your own DLL. Even if the studio somehow altered the DLL you provided them, you can make sure that their illegal changes are undone by simply using your own version of your own DLL.

  • 1
    No. Your objections to version control as the solution are based on a fundamental misunderstanding of what it offers and how it is supposed to be used. Your alternative of hiding the code in a binary library is a bad idea, because it makes it hard for the cooperating parties to understand root causes, try possible changes locally and suggest fixes for review. What you are proposing is an old, inefficient approach from the days before version control, that is fortunately being abandoned across the industry and outcompteted in the few cases someone tries to stay with it. – Chris Stratton Apr 4 at 23:40
  • @ChrisStratton: "Let's hope a human catches it" is not an adequate replacement for proper access control (note: I'm not saying human code reviews should not be done; I'm saying they shouldn't be the last and only line of defense). In most cases, all developers on a project are equal contributors (who may specialize in part of the project but are not inherently restricted to that part). In OP's situation, that is decidedly not the case. I do agree that it would be much nicer if the VCS had proper file access restrictions (read/write/...) but as far as I'm aware that is simply not the case. – Flater Apr 5 at 11:29
  • @ChrisStratton: I full well agree that file exchange is inferior to VCS in general. I wouldn't want to go back to manual file sharing. However, if the VCS does not provide a level of security that OP's company requires, then they can't rely on the VCS alone and will have to implement their own security on top of that. My suggestion of Nuget is nowhere near anti-VCS. If anything, it relies on the company using VCS to manage the release of their source code to external partners. – Flater Apr 5 at 11:31
  • A VCS as used by a well organized project does provide the level of security you seek, the issue is that you seem not to have seen one used correctly – Chris Stratton Apr 5 at 14:59

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