Re: Transparently encrypt repository contents with GPG

From: Jeff King <peff@peff.net>
Date: Mar 17, 2009, 08:22 UTC
Message-ID: <20090317082239.GF18475@coredump.intra.peff.net>
In-Reply-To: <7vy6v9f9zn.fsf@gitster.siamese.dyndns.org>

On Fri, Mar 13, 2009 at 01:23:08PM -0700, Junio C Hamano wrote:

Show 7 quoted lines

> As the sole raison d'etre of diff.textconv is to allow potentially lossy
> conversion (e.g. msword-to-text) applied to the preimage and postimage
> pair of contents (that are supposed to be "clean") before giving a textual
> diff to human consumption, the above config may appear to work, but if you
> really want an encrypted repository, you should be using an encrypting
> filesystem.  That would give an added benefit that the work tree
> associated with your repository would also be encrypted.

I can think of one reason that having git do the encryption might be beneficial: pushing to an untrusted source.

If you encrypted all blobs but kept trees and commits in plaintext, you could retain (some of) the benefits of git's incremental push. The downsides, though, are:

  1. You are revealing the hashes of your blobs' plaintext. Which means
     I can try brute-forcing your blobs by checking against a hash
     function.

  2. The remote can't actually look at the blobs. The most obvious
     problem with this is that you can't send it thin packs, since it
     can't actually resolve deltas.

And given the ensuing mess that it would make of the code to conditionally say "Oh, we have this object, but you're not allowed to read it", it is almost certainly not worth it.

But maybe somebody can prove me wrong and design a system that allows efficient encrypted pushing to a non-trusted remote and also doesn't suck.

-Peff