Re: git, monorepos, and access control

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 6, 2018, 01:08 UTC
Message-ID: <xmqqwoona2c6.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20181205210104.GC19936@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> 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.
> ...

Yup, with s/implemented/designed/, I agree all you said here (snipped).

> 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).

Yup, again.

Storing source files encrypted and decrypting with smudge filter upon checkout (and those without the access won't get keys and will likely to use sparse checkout to exclude these priviledged sources) is probably the only workaround that does not involve submodules. Viewing "diff" and "log -p" would still be a challenge, which probably could use the same filter as smudge for textconv.

I wonder (and this is the primary reason why I am responding to you) if it is common enough wish to use the same filter for smudge and textconv? So far, our stance (which can be judged from the way the clean/smudge filters are named) has been that the in-repo representation is the canonical, and the representation used in the checkout is ephemeral, and that is why we run "diff", "grep", etc. over the in-repo representation, but the "encrypted in repo, decrypted in checkout" abuse would be helped by an option to do the reverse---find changes and look substrings in the representation used in the checkout. I am not sure if there are other use cases that is helped by such an option.