Re: Transparently encrypt repository contents with GPG

From: Jeff King <peff@peff.net>
Date: Mar 13, 2009, 17:13 UTC
Message-ID: <20090313171312.GB16504@sigill.intra.peff.net>
In-Reply-To: <49BA6606.1070403@fastmail.fm>

On Fri, Mar 13, 2009 at 02:56:22PM +0100, Michael J Gruber wrote:

Show 16 quoted lines

> Sverre was being prophetic with the somehow. Here's a working setup
> (though I still don't know why not to use luks):
> 
> In .gitattributes (or.git/info/a..) use
> 
> * filter=gpg diff=gpg
> 
> In your config:
> 
> [filter "gpg"]
>         smudge = gpg -d -q --batch --no-tty
>         clean = gpg -ea -q --batch --no-tty -r C920A124
> [diff "gpg"]
>         textconv = decrypt
> 
> This gives you textual diffs even in log! You want use gpg-agent here.

This is not going to work very well in general. Smudging and cleaning is about putting the canonical version of a file in the git repo, and munging it for the working tree. Trying to go backwards is going to lead to problems, including:

  1. Git sometimes wants to look at content of special files inside
     trees, like .gitignore. Now it can't.

  2. Git uses timestamps and inodes to decide whether files need to be
     looked at all to determine if they are different. So when you do
     a checkout and "git diff", everything will look OK. But when it
     does actually look at file contents, it compares canonical
     versions. And your canonical versions are going to be _different_
     everytime you encrypt, even if the content is the same:

       echo content >file
       git add file
       git diff ;# no output
       touch file
       git diff ;# looks like file is totally rewritten

     So you will probably end up with extra cruft in your commits if you
     ever touch files.

> Now for Sverre's prophecy and the helper I haven't shown you yet: It
> turns out that blobs are not smudged before they are fed to textconv!
> [Also, it seems that the textconv config does allow parameters, bit I
> haven't checked thoroughly.]

I don't think they should be smudged. Smudging is about converting for the working tree, and the diff is operating on canonical formats. If anything, I think the error is that we feed smudged data from the working tree to textconv; we should always be handing it clean data (and this goes for external diff, too, which I suspect behaves the same way).

I haven't looked, but it probably is a result of the optimization to reuse worktree files.

-Peff

PS If it isn't obvious, I don't think this smudge/filter technique is the right way to go about this. But one final comment if you did want to pursue this: you are using asymmetric encryption in your GPG invocation, which is going to be a lot slower and the result will take up more space. Try using a symmetric cipher.