Matthias Andree venit, vidit, dixit 17.07.2009 17:14: > Greetings, > > 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. > > Requirements: > - "client" that is about to push must encrypt the data before pushing it > to the server. > - all data (including file names, log messages, > > Allowed restrictions: > - "server" limited to bare repositories > - initial version limited to symmetric encryption with pre-shared secret > > In a later step, some key management and asymmetric crypto would be > useful, but that's not crucial now. In my current scenario, those who are > working on the embargoed material would trust one another. > > > How would one go about this from the user side? I sincerely doubt I have > the resources (time!) to actually implement this in Git. 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. So, why not share some form of remote storage on which you have an encrypted luks partition? That way you can even set up multiple access keys and revoke them when necessary. Michael -- 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