Open source software development is great, and there exists an abundance of difference git solutions to create public and private repositories for collaboration and distribution. Private repos give you an extra layer of control by not allowing your code base to be seen by the public. Occasionally you may have a project that you want to be able to collaborate with a limited set of remote people, and want restrict the possiblity of your source being viewed, even by the git service provider. None of the commercial git providers have a good solution for this currently, at least that I know of.

After some research I found that Keybase.io does offer a potential solution, but this requires all of your colloborators to create an account through keybase. While reading about their solution, I found out that they primarly use a custom git remote-helper for the encryption/decryption on the client side. That led me to find git-remote-gcrypt, a GPG solution for encrytped git repositories. As well, I came across an article from 9to5Answer of setting up encrypted git repositories and inspired me to test it out.

Walkthrough

Environment

  • Ubuntu 22.04 Desktop
  • GitLab with SSH keys configured
  • GitHub with SSH keys configured

Steps

1.Make sure your system is fully up to date and install the git-remote-gcrypt and gpg packages

sudo apt udpate
sudo apt upgrade -y
sudo apt install git-remote-gcrypt gpg
  1. If you dont have GPG keys already, you will need to generate them. I am not expert in GPG and just used the commands listed below for testing, but the 9to5Answer article links to Alex Cabal’s post to get a better idea on creating a GPG key. We will also need to grab the keys fingerprint for later.
gpg --gen-key
gpg --list-keys

  1. Create the repository on the remote git solution (GitHub / GitLab). We called our repo crypt-test on both platforms.

  2. Set up the local repository, we can either clone and modify the remotes here or we can initialize a local and add the new remote. We will call the remote crypt-origin in the walkthrough. This if all for a brand new repo.

    a. Clone and modify remotes

# CLONE AND MODIFY REMOTES
git clone <GIT URL>
cd <GIT REPO>
git remote remove origin
git remote add crypt-origin gcrypt::<GIT URL>

# Initialize local and add remotes from a blank directory
git init
git branch -m main
git remote add crypt-origin gcrypt::<GIT URL>
  1. We need to then configure our repo to allow our GPG key. The last command is optional and will remove anonymity and allow others to see who is contributing to the project. Without that command you will have to cycle through your keypairs, if you have multiple, as described in more detail on the 9to5Answer article.
git config remote.crypt-origin.gcrypt-participants <GPG FINGERPRINT>
git config remote.crypt-origin.gcrypt-signingkey <GPG FINGERPRINT>
git config remote.crypt-origin.gcrypt-publish-participants
  1. I am not sure if this was environmental or what and need to do more research, but while in bash/tmux I had to export GPG_TTY, as shown below, to allow for gpg to prompt for my passphrase and actually work. Other than that, you can start working with git as normal.
export GPG_TTY=$(tty)
git add *
git commit -asm "My commit message"
git push crypt-origin main

Warnings and Information

  • Read the 9to5Answer Article for some of the warnings and issues they bring up.
  • All push will implicity set the --force flag
  • A push must pull the repo, decrypt, do the push locally, encrypt and then push the encrypted data back to the remote. I have not done the research to see if there is any sort of solution to deal with race conditions on pushes, but I forsee that being a potential issue with this solution.
  • On early attempts to use this solution I seemed to corrupt my repo when I did not have GPG_TTY exported. As stated early, I am not a GPG expert and really have very little experience with GPG so there is probably some good information out there on ways to make this work better.
    • I saw in some article that you could use a key without a passphrase, but then you lose that extra protection of your key.
  • While it may seem obvious once you think about it, its worth mentioning that because everything on the remote end is encrypted, pretty much all of the Web UI functionality is useless in the different git solutions. Any collaborators should be comfortable working with git locally, including merging and handling merge issues.

Final Thoughts

The fact is that there are very few solutions out there that implement solutions to the problem that is trying to be solved with this solution and most users probably dont need anything like this. With that in mind and the limited choices for remote encrypted git, I think that this solution is feasible and will hopefully continue to mature. Now that I am aware of this solution, I will continue to test it out and see how I can contribute to progessing it further to hopefully come to an easy to use and robust solution for encrypted remote git repos.