Re: git, monorepos, and access control

From: Jeff King <peff@peff.net>
Date: Dec 6, 2018, 07:23 UTC
Message-ID: <20181206072300.GB29787@sigill.intra.peff.net>
In-Reply-To: <cdeb9dc9-ac25-23c8-f3b9-9a7987be7df0@amd.com>

On Wed, Dec 05, 2018 at 11:42:09PM +0000, Coiner, John wrote:

Show 12 quoted lines

> > 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).
> Another good point. I wouldn't have thought of either of these attacks. 
> You're scaring me (appropriately) about the risks of adding security to 
> a previously-unsecured interface. Let me push on the smudge/clean 
> approach and maybe that will bear fruit.

If you do look into that approach, check out how git-lfs works. In fact, you might even be able to build around lfs itself. It's already putting placeholder objects into the repository, and then faulting them in from external storage. All you would need to do is lock down access to that external storage, which is typically accessed via http.

(That all assumes you're OK with sharing the actual filenames with everybody, and just restricting access to the blob contents. There's no way to clean/smudge a whole subtree. For that you'd have to use submodules).

-Peff