inline... On 12/05/2018 04:12 PM, Ævar Arnfjörð Bjarmason wrote: > On Wed, Dec 05 2018, Duy Nguyen wrote: > >> >> 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. Ah, clean/smudge has potential. It locates the security boundary entirely outside the git service and outside the repo. No big software engineering project is needed. It should work in VFSForGit just as it does in plain old git. Beautiful! For our use case, it might be OK for commit logs, branch names, and filenames to be world-readable. Commit logs are probably the greatest concern; and perhaps we could address that through other means. Maybe it's possible to design a text-to-text cipher that still permits git to store compact diffs of ciphered text, with only modest impact on security? Thank you all for your thoughtful replies. > > This is a thing I know *way* less about so maybe I'm completely wrong, > but even if we have all the rest of the things outlined in your post to > support this, isn't this part going to be susceptible to timing attacks? That's a good point. It's not easy to estimate exposure to something like this. > 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. Thanks again. - John
