1

Our git repositories typically contain code for our entire websites & services. This includes all painstakingly worded text for marketing, legal, UI, etc.

Essentially a rogue developer could clone it, change a few things, and become a competitor of ours (all legal issues aside). Or more likely, they often will include others work as their own in their portfolios without authorization. In some cases this leads to early disclosure of features and functions we don't want out there yet.

In any case, this has been recognized as a risk since we occasionally work with developers around the globe and have need to add more soon -- granting them access to the entire code base that they will work on.

Have you ever encountered this issue? Or have implemented a solution to reduce or mitigate similar risks?

I am thinking one potential strategy could be to create 3 individual git REPOSITORIES with different purposes (not branches) but something like this:

Git Repo: Project1_DEVELOPERS

$git branch
master
dev
issue_feature1
issue_feature2
etc..

Workflow above: Is basically issue/feature branch style. A developer is delegated a task, checks it out as a issue/feature branch. When completed, submits that branch & merge request into dev branch. We test the branch & merge to dev if OK.

Above is basically how we do things today. That's it. The whole repo is there in 'master' as it gets published to the world.

But to meet the stated goal I'm thinking to ADD something like...

Git Repo: Project1_OBFUSCATE

$git branch
strips_and_swaps (for sending to DEVELOPERS repo)
prod_patches (the patches to make it "whole" again)
prod_master (branch that PRODUCTION repo pulls into its master branch?)

and the production repo...

Git Repo: Project1_PRODUCTION

$git branch
master

As far as content for the problem goes, imagine simple webpage as repo...

.git
index.html
logo.png

So my goal would be to strip out or patch in a real/fake "logo.png" with dummy logo from the branches that are in the "DEVELOPERS" repo.

In practice, instead of just a logo.png, maybe it would be a bunch of .blade files (Laravel) .twig files or whatever template files that might have content bits that we wish to restrict access to. In some cases, maybe the files ONLY exist in teh "OBFUSCATE" remote.

Has anyone done anything similar to this who might share some insight?

It hurts my head to think about doing this the way I'm suggesting, and it might not even work :)

LittleBobbyTables - Au Revoir
  • 32,008
  • 25
  • 109
  • 114
JG707
  • 245
  • 1
  • 7
  • 13
  • 2
    Obfuscation would be a tiny speedbump to someone determined to steal your IP. This is not a risk you can mitigate with technology. Have clear, well-defined enforceable contracts, work with people you can trust and you can get good references for,etc. Also consider the signal you're sending your contractors - you're basically telling them you think they're untrustworthy and potential thieves. – pvg Jul 11 '15 at 07:16
  • Costco offers free samples food stuffs; yet if you listen closely, you'll overhear many people asking people they're with to retrieve one for them :) The risk we're trying to mitigate is having our entire CURRENT products (verbatim as published/released) in the hands of every overseas developer we work with. As a complete "turn-key" work things have more value than RTA (ready to assemble, just add logos, css styles, legal jargon, and other mucky muck). We want to increase # developers, but with each addition we increase risk to the products. Lots of great developers & lots of bad ones, too. – JG707 Jul 11 '15 at 07:26
  • That's not a very sensible analogy - it's minor cheating, like a developer billing you for the 15 minutes they went to get coffee. You don't hear people helping themselves to a second cube of cheddar on a toothpick also planning an armed robbery. If you have very sensitive IP, don't give it to people you don't trust. Obfuscation will do absolutely nothing to prevent a bad actor stealing from you. The solution is to avoid working with bad actors. In many years of working with offshore teams, I've never seen or heard what you're describing happening. – pvg Jul 11 '15 at 07:34
  • It certainly happens in more complex IP situations like JVs. But a well-referred, well vetted offshore developer or team? It would be basically business suicide for them as well. – pvg Jul 11 '15 at 07:36
  • It's sort of like saying every time you've worked for an enterprise that protected their expensive IT assets behind a locked door that they were telling you that you're untrustworthy & a potential thief. I think what's behind the door is none of your concern. They've given you just enough (like a laptop & a monitor) to do your work. Why do you care if the rest of the stuff is off limits to you? Especially if I'm the one who has to manage and be responsible for the door lock and and the asset/inventory management. – JG707 Jul 11 '15 at 07:54
  • re: "In many years of working with offshore teams, I've never seen or heard what you're describing happening." If you've ever browsed portfolios of freelancers on the various freelancing platforms out there, you would see a high number of violations of the platforms default NDA's. You could say "how do you know it's not with permission?" -- answer is because often the content that is being shared with the world would NEVER be approved by its rightful owners. – JG707 Jul 11 '15 at 08:06
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/83019/discussion-between-jg707-and-pvg). – JG707 Jul 11 '15 at 08:13

1 Answers1

3

The best practice is, if possible, to isolate sensitive information in their own Git repo instead of keeping everything in one giant repo.

You still can have a global picture by using a parent repo which would reference all the other repos as submodules.

But if the sensitive data is in one repo, you can then protect it in term of access.
This is easier than trying to protect a branch (you can protect against push, not pull, meaning one can still have access to its content) or obfuscate a remote url.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks, I'll look into git submodules and see if this can help us. Right..sorry... I guess I didn't mean REMOTES within a single repo. I meant independent REPO's. I'll clarify that. – JG707 Jul 11 '15 at 07:06
  • @JG707 OK. The idea remain: if the sensitive data is isolated in its own repo, it is much easier to control who can clone it (ie, not a "rogue developer"). – VonC Jul 11 '15 at 07:11
  • Yes, it's really the HOW part that I'm trying to understand for the process of stripping/swapping data for the developers and then stripping/swapping it again for our own "real" production version. – JG707 Jul 11 '15 at 07:17
  • @JG707 the question is: does the developer needs that sensitive repo at all (for developing on the rest of the app)? Because when cloning the parent repo, all submodules will be cloned except the one(s) he/she doesn't have access to. – VonC Jul 11 '15 at 07:19
  • No, absolutely not. I'm talking about logos, artwork, marketing text, corrected text for prompts and menus, things like this. Thanks again, I'm definitely going to look into submodules in the AM when I have both coffee & motivation. only 1of2 at the moment :) I'll mark answer then if this works for us. – JG707 Jul 11 '15 at 07:33
  • While searching out some images of "Submodules" workflow examples, I wound up looking at this as well... http://typecastexception.com/post/2013/03/16/Managing-Nested-Libraries-Using-the-GIT-Subtree-Merge-Workflow.aspx it's giving me the idea that I could have 2 "shared library" repos in my case. One for developer placeholder data, and one for the real production data. Maybe that's how submodules works, too. – JG707 Jul 11 '15 at 08:00
  • @JG707 sure, I mention the alternative (subtree) here: http://stackoverflow.com/a/28472022/6309, that I also illustrated in http://stackoverflow.com/questions/24709704/apply-gradle-file-from-different-repository/24709789#24709789. – VonC Jul 11 '15 at 08:02