On Thu, Mar 13, 2008 at 11:53:22AM -0400, Jeff King wrote: > - encrypting whole packfiles is a bit better for transport. The > key-holding repo does the deltas and just treats the remote repo as > dumb storage (it can't be smart, since that would involve looking at > the data). Storage overhead is minimal if packfiles are a reasonable > size. > > So I think the last makes the most sense, where your local repo is > totally unprotected, but you efficiently push git objects to a remote > untrusted repo. 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. > - 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 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? :-) - Ted -- 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
