Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > Matthias Andree venit, vidit, dixit 17.07.2009 17:14: > > > > I have a rather special usage scenario. > > > > Assume you have a repository where you want to work on embargoed > > information, so that not even system administrators of the server you're > > pushing to can get a hold of the cleartext data. > > > > "Server" would be a central reference repository that I can push to. > > "Client" would by my working computer that has a clone of the crypted > > repo, and an unencrypted checkout of it. Perhaps the client would also > > need an unencrypted copy of the repo (for performance reasons, I'm not > > sure about that) that gets encrypted on the fly when pushing and decrypted > > when fetching. > > > > Examples of use might be press releases of upcoming products, written > > exams for students, whatever. > If the server can not decrypt anything then it can not serve anything, > at least not as a git server. Note that if you're really fussy about > security then you should not allow the server to see even the DAG (which > would be the case if you encrypt blobs only), which makes it impossible > to do any smart serving. There was shown here on git mailing list script which was meant to help in situation where you have repository with sensitive deta, discovered repository corruption or bug in git, and cannot be reproduced otherwise. But I think it didn't encrypt repositry, but just emulate it's structure. As to encrypting repository: you can encrypt blobs (content of files), you can encrypt filenames (but the structure remains) or you can put files in a flat encrypted structure, and you can encrypt commit messages and comitter and author info, and encrypt / rename branch names. Still some DAG structure will be visible, and need be visible for "smart" git server (access via ssh and git protocols) to work. -- Jakub Narebski Poland ShadeHawk on #git -- 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