Re: git, monorepos, and access control

From: Duy Nguyen <pclouds@gmail.com>
Date: Dec 5, 2018, 20:58 UTC
Message-ID: <CACsJy8AzMvG3U5GnVkn0Ax3XP3NnPCwwc1AzdVV9JkePfMjwWg@mail.gmail.com>
In-Reply-To: <a5a3009e-346e-2b63-5b7c-3e9daf0c7de2@gmail.com>

On Wed, Dec 5, 2018 at 9:46 PM Derrick Stolee <stolee@gmail.com> wrote:

Show 8 quoted lines

> This directory-level security is not a goal for VFS for Git, and I don't
> see itbecoming a priority as it breaks a number of design decisions we
> made in our object storage and communication models.
>
> The best I can think about when considering Git as an approach would be
> to use submodules for your security-related content, and then have server-
> side security for access to those repos. Of course, submodules are not
> supported in VFS for Git, either.

Another option is builtin per-blob encryption (maybe with just clean/smudge filter), then access control will be about obtaining the decryption key (*) and we don't break object storage and communication. Of course pack delta compression becomes absolutely useless. But that is perhaps an acceptable trade off.

(*) Git will not cache the key in any shape or form. Whenever it needs to deflate an encrypted blob, it asks for the key from a separate daemon. This guy handles all the access control.

Show 8 quoted lines

> The Gerrit service has _branch_ level security, which is related to the
> reachability questions that a directory security would need. However,
> the problem is quite different. Gerrit does have a lot of experience in
> dealing with submodules, though, so that's probably a good place to
> start.
>
> Thanks,
> -Stolee

-- 
Duy