Re: git, monorepos, and access control

From: Jeff King <peff@peff.net>
Date: Dec 5, 2018, 21:01 UTC
Message-ID: <20181205210104.GC19936@sigill.intra.peff.net>
In-Reply-To: <939efd87-b2af-29d7-efdd-9cf8f6de9d10@amd.com>

On Wed, Dec 05, 2018 at 08:13:16PM +0000, Coiner, John wrote:

Show 12 quoted lines

> One obstacle to moving AMD to git/VFSForGit is the lack of access 
> control support in git. AMD has a lot of data whose distribution must be 
> limited. Sometimes it's a legal requirement, eg. CPU core designs are 
> covered by US export control laws and not all employees may see them. 
> Sometimes it's a contractual obligation, as when a third party shares 
> data with us and we agree only to share this data with certain 
> employees. Any hypothetical AMD monorepo should be able to securely deny 
> read access in certain subtrees to users without required permissions.
> 
> Has anyone looked at adding access control to git, at a per-directory 
> granularity? Is this a feature that the git community would possibly 
> welcome?

In my opinion this feature is so contrary to Git's general assumptions that it's likely to create a ton of information leaks of the supposedly protected data.

For instance, Git is very eager to try to find delta-compression opportunities between objects, even if they don't have any relationship within the tree structure. So imagine I want to know the contents of tree X. I push up a tree Y similar to X, then fetch it back, falsely claiming to have X but not Y. If the server generates a delta, that may reveal information about X (which you can then iterate to send Y', and so on, treating the server as an oracle until you've guessed the content of X).

You could work around that by teaching the server to refuse to use "X" in any way when the client does not have the right permissions. But:

  - that's just one example; there are probably a number of such leaks

  - you're fighting an uphill battle against the way Git is implemented;
    there's no single point to enforce this kind of segmentation

The model that fits more naturally with how Git is implemented would be to use submodules. There you leak the hash of the commit from the private submodule, but that's probably obscure enough (and if you're really worried, you can add a random nonce to the commit messages in the submodule to make their hashes unguessable).

> I would welcome your feedback on whether this idea makes technical 
> sense, and whether the feature could ever be a fit for git.

Sorry I don't have a more positive response. What you want to do is perfectly reasonable, but I just think it's a mismatch with how Git works (and because of the security impact, one missed corner case renders the whole thing useless).

-Peff