Michael J Gruber [off-list ref] writes:
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.
Don't do this.
Think why the smudge/clean pair exists.
The version controlled data, the contents, may not be suitable for
consumption in the work tree in its verbatim form. For example, a cross
platform project would want to consistently use LF line termination inside
a repository, but on a platform whose tools expect CRLF line endings, the
contents cannot be used verbatim. We "smudge" the contents running
unix2dos when checking things out on such platforms, and "clean" the
platform specific CRLF line endings by running dos2unix when checking
things in. By doing so, you can see what really got changed between
versions without getting distracted, and more importantly, "you" in this
sentence is not limited to the human end users alone.
git internally runs diff and xdelta to see what was changed, so that:
* it can reduce storage requirement when it runs pack-objects;
* it can check what path in the preimage was similar to what other path
in the postimage, to deduce a rename;
* it can check what blocks of lines in the postimage came from what other
blocks of lines in the preimage, to pass blames across file boundaries.
If your "clean" encrypts and "smudge" decrypts, it means you are refusing
all the benifit git offers. You are making a pair of similar "smudged"
contents totally dissimilar in their "clean" counterparts. That is simply
backwards.
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.
Junio C Hamano venit, vidit, dixit 13.03.2009 21:23:
Michael J Gruber [off-list ref] writes:
quoted
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.
Don't do this.
Think why the smudge/clean pair exists.
The version controlled data, the contents, may not be suitable for
consumption in the work tree in its verbatim form. For example, a cross
platform project would want to consistently use LF line termination inside
a repository, but on a platform whose tools expect CRLF line endings, the
contents cannot be used verbatim. We "smudge" the contents running
unix2dos when checking things out on such platforms, and "clean" the
platform specific CRLF line endings by running dos2unix when checking
things in. By doing so, you can see what really got changed between
versions without getting distracted, and more importantly, "you" in this
sentence is not limited to the human end users alone.
git internally runs diff and xdelta to see what was changed, so that:
* it can reduce storage requirement when it runs pack-objects;
* it can check what path in the preimage was similar to what other path
in the postimage, to deduce a rename;
* it can check what blocks of lines in the postimage came from what other
blocks of lines in the preimage, to pass blames across file boundaries.
If your "clean" encrypts and "smudge" decrypts, it means you are refusing
all the benifit git offers. You are making a pair of similar "smudged"
contents totally dissimilar in their "clean" counterparts. That is simply
backwards.
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.
Exactly. This is why I suggested using cryptfs/luks in my first response
already.
But I don't know the OP's requirements, which is why I also told him how
to do what he wanted, even though it has the drawbacks you and Jeff (and
maybe I) mentioned. Maybe it's an attempt at hosting a semi-private repo
on a public (free) server?
Besides the non-text nature of encrypted content, the problem here is
that d(e(x))=x for all x but e(d(x)) differs from x most probably, and
hopefully randomly, unless you use the right version of debian's openssl
of course ;)
That being said:
git diff calls textconv filters with smudged as well as cleaned files
(when diffing work tree files to blobs), and this does not seem right. I
hope this is not happening with the internal diff, nor with crlf!
Since both the cleaned and the smudged version are supposed to be
"authoritative" (as opposed to the textconv'ed one) one may argue either
way what's the right approach. For internal use comparing the cleaned
versions may make more sense, for displaying diff's the checked-out
form, i.e. smudged versions make more sense.
But that is another topic which would need to be substantiated with
tests. It's not completely unlikely I may come up with some, but don't
count on it...
Cheers,
Michael
On Fri, Mar 13, 2009 at 01:23:08PM -0700, Junio C Hamano wrote:
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