Re: [Q] Encrypted GIT?

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

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.

quoted

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

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