Repository files navigation

This is a git remote helper that allows for full transparent encryption of gitrepositories on unsecure remote locations.

This is still experimental. Encryption format is still not stable, which mightrequire you to re-encrypt your data if you update to a future version.

So use at your own risk and expect some weird errors. Because of this statethe installation is also a bit more nerdy than what you might expect.

If you see issues with the installation or usage, feel free to open an issueathttps://github.com/schiele/git-incrypt/issues. Be aware that this is ahobby project of mine, so read the issues from other people first that mightbe related to your problem, be polite, and provide all information necessaryto properly understand your problem, including what you intended to do, whatcommand you invoked and what was the output the tool produced.

If you have suggestions on how to improve things, feel free to provide them aswell. Optimally you provide even a pull request but just opening an issue isalso welcome.

To make this work you first need to install pygit2. Either use yourdistribution's package manager or alternatively invoke:

pip install pygit2

Next you either need to put this directoy inside your system search path orlink or copy the filesgit-incrypt andgit-remote-incrypt to somedirectory that is in the system search path.

I recommend you configure GPG to use an agent and it is likely not a good ideato receive password prompts during git operations.

Use the following command to create a new encrypted repository:

git incrypt init $URL $GPG_KEY_ID

where$URL is the URL of the remote repository prefixed withincrypt:: tobe initialized and$GPG_KEY_ID is one or multiple GPG key IDs to be used toencrypt the data in the repository. Note that this version does not yet have acommand to change the list of keys later, so give it a thought before settingup the repository. However if you need to change keys you can always deletethe encrypted repository later and re-initialize it with other keys. For surewe should have a command in future versions that an re-encrypt the data withnew keys in the future.

From now on you can just use the regular git commands to communicate with theencrypted remote repository. They all should work in the ususal way butwhenever you need to supply the remote URL to the encrypted repository youneed to prefix it withincrypt::, for example when your remote storage placeis:

git@github.com:schiele/git-incrypt-crypted.git

you provide instead:

incrypt::git@github.com:schiele/git-incrypt-crypted.git

For a fresh clone of the encrypted repository this would be for example:

git clone incrypt::git@github.com:schiele/git-incrypt-crypted.git

To add an encrypted remote to an existing repository this would be somethinglike:

git remote add crypted incrypt::git@github.com:schiele/git-incrypt-crypted.git

Within the repositories you can use commands likegit pull,git fetch, orgit push without special considerations.

A sketch of the repository format can be found inFORMAT.md.

The approach we take here is to completely encrypt every single git object.With this approach no filters need to get applied as withhttps://www.agwa.name/projects/git-crypt/ but all action happens when fetchingor pushing data to the remote.

There ishttps://github.com/spwhitton/git-remote-gcrypt that operate as aremote helper, similar to this one but they compress the complete pack files,making incremental changes on arbitrary git URLs expensive since thispotentially requires re-transmitting large pack files.

Our approach has advantages and disadvantages compared to those otherapproaches:

Compared with the first project above we do not need any particular filterconfiguration we could get wrong and might leak data by accident. For surethis comes with the downside that we either encrypt the whole repository or wedon't. There is no partial encryption possible. On the other hand our approachallows pushing the same git repository to an unencrypted remote in a securelocation, like a local server and duplicate the same on an encrypted remote inpublic space to exchange the code with other trusted parties.

Compared with the second approach we can perform incremental changes to thegit repository in a more efficient way. If there is only a small change on theunencrypted repository, this causes only a small change to the encryptedrepository, while the other approach might require large transfers of the packfiles changed. On the other side our approach does reveal more informationabout the repository structure in the sense that a potential attacker cancount the amount of branches or tags that do exist and can count the amount ofcommits in each branch and their structural relationships to each other. Anattacker could not see who created them or when they were created.

Since we encrypt each object separately we also pay a price by a spaceincrease of the overall repository of a bit less than a ten-fold increase.This is caused by the fact that the delta algorithm in git can no longerdetect similarities between the individual encrypted objects. Since in atypical workflow changes to the repository are of small increments though thespeed increase is likely worth it. Also the initial encryption of an alreadyvery large repository can take quite some time. Encrypting the complete sourcerepository of git takes about 45 minutes on my current laptop. The performancepenalty seems only relevant though for the expensive initial encryption. ---And after all most users will have significantly smaller repositories comparedto the repository of git itself.

The way we encrypt individual objects might reveal data that an attacker coulduse to undermine the encryption, though I tried to mitigate the risks whereverI saw one. A more detailed analysis and discussion should follow in the futurein this document. Should you identify a problem, I am for sure interested inlearning about it.

At the moment the implementation is still quite experimental with bad errorhandling and a lot of technical debt in the code.

But you are free to already look around here and play with the tool. Furtherdocumentation will follow.

You can also find an encrypted version of this repository athttps://github.com/schiele/git-incrypt-crypted/ for you to see how things looklike on the ecrypted side.