Re: [Q] Encrypted GIT?

On Thu, Mar 13, 2008 at 11:53:22AM -0400, Jeff King wrote:

  - encrypting whole packfiles is a bit better for transport. The
    key-holding repo does the deltas and just treats the remote repo as
    dumb storage (it can't be smart, since that would involve looking at
    the data). Storage overhead is minimal if packfiles are a reasonable
    size.

So I think the last makes the most sense, where your local repo is
totally unprotected, but you efficiently push git objects to a remote
untrusted repo.

If the main goal is primarily backup of your repository to an
untrusted remote server, yes, that makes perfect sense.  

If you assume multiple trusted developers would actually be
*operating* on an encrypted repo, the life gets much harder, as you've
pointed out.

  - encrypting before git sees content sucks, because you are either
    sacrificing security (content X always encrypts to Y) or system
    stability (git doesn't know that Y and Y' are really the same thing)

It's not clear that "content X always encrypts to Y" is a fatal flaw,
by the way.  Yes, it leaks a bit of information, but in a source code
management situation, it may not matter.  If you do absolutely care,
tough, it might be that the simplest solution is to store the entire
repository and working tree under cryptofs.  After all, what's the
point of encrypting the local repo if the checked-out working tree is
unprotected for all to see?  :-)

						- Ted