On Wed, Dec 05 2018, Duy Nguyen wrote:
> On Wed, Dec 5, 2018 at 9:46 PM Derrick Stolee <sto...@gmail.com> wrote: >> 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. Right, this is another option, but from what John described wouldn't work in this case. "Any hypothetical AMD monorepo should be able to securely deny read access in certain subtrees to users without required permissions". I.e. in this case there will be a secret-stuff-here/ryzen-microcode.code.encrypted or whatever, unauthorized users can't see the content, but they can see from the filename that it exists, and from "git log" who works on it. It'll also baloon in size on the server-side since we can't delta any of these objects, they'll all be X sized encrypted binaries. > (*) 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. > >> 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
