[michaelmior]

Thanks for sharing this. It's a good walkthrough and potentially quite useful for anyone wanting to implement a new protocol. It seems like the wrong tool for the job to me however.

This seems like it would be more easily implemented with smudge/clean filters[0]. In fact, this is exactly what git-crypt[1] does. The idea is that you run a filter on every file as it's checked out to do the decryption and every time a file is staged to do encryption. This requires nothing extra on the remote repository and you can you git commands as normal.

[0] http://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes [1] https://github.com/AGWA/git-crypt

[JoshTriplett]

Depends on the behavior you want. With smudge/clean filters, the files in the repository history are encrypted. That means you don't get the benefit of delta encoding, and any tools you have that look directly at the repository (such as gitk or anything based on libgit2) cannot operate on the cleartext data.

On the other hand, git-remote-gcrypt (https://github.com/joeyh/git-remote-gcrypt/) encrypts when pushing and decrypts when pulling, which leaves the local repository unencrypted but keeps it encrypted on the untrusted remote server.

[michaelmior]

That's a fair point :) Although I do like the fact that the smudge/blur approach means that you can selectively encrypt files as well as still share the entire repository publicly via any protocol.

[JoshTriplett]

True. And it also has the advantage of failing closed (if you accidentally push to the wrong place) rather than failing open.

[frutiger]

Smudge/clean filters will reveal the metadata of the repository (directory structure, file names, etc.)