Re: [Q] Encrypted GIT?

From: Jeff King <peff@peff.net>
Date: Mar 13, 2008, 16:19 UTC
Message-ID: <20080313161919.GA2050@coredump.intra.peff.net>
In-Reply-To: <20080313161201.GA31653@mit.edu>

On Thu, Mar 13, 2008 at 12:12:01PM -0400, Theodore Tso wrote:

Show 6 quoted lines

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

Well, it depends on the meaning of "operate". :) I think you could still use it as a rendezvous point as you would any bare repository. Pushing and pulling would have a little larger network overhead, and a lot more CPU overhead.

But yes, that scheme is horrible for a working repo.

Show 6 quoted lines

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

Agreed (I actually recommended in Dscho's original thread "you can do it by eliminating the salt, if you accept the consequences...").

So after my saying "no formal threat analysis is necessary" you have clearly called me on making a bunch of usage assumptions. Oops. :)

Show 5 quoted lines

> 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?  :-)

Yes. And it doesn't involve any git-specific code at all. :)

-Peff