On Thu, Mar 13, 2008 at 12:12:01PM -0400, Theodore Tso wrote: > 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. Well, it depends on the meaning of "operate". :) I think you could still use it as a rendezvous point as you would any bare repository. Pushing and pulling would have a little larger network overhead, and a lot more CPU overhead. But yes, that scheme is horrible for a working repo. > > - 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 Agreed (I actually recommended in Dscho's original thread "you can do it by eliminating the salt, if you accept the consequences..."). So after my saying "no formal threat analysis is necessary" you have clearly called me on making a bunch of usage assumptions. Oops. :) > 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? :-) Yes. And it doesn't involve any git-specific code at all. :) -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
