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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
