Setting up an encrypted git-repository

Question

Situation

Hi, I would like to save data with git, encrypted (on some platform like bitbucket or github). Therefore the question:

Question

I am looking for different hassle-free ways on:
How to set up an encrypted repository on bitbucket(/github)? Now, I am new to git, thus an instruction with all necessary steps or step by step would be much appreciated!

"Research"

git-crypt
I found git-crypt, but on the site it is mentioned that it's intended for single file encryption. If one wanted to encrypt the whole repository they forward to git-remote-gcrypt.

git-remote-gcrypt
In their README.rst they put it as simple as

Quickstart

git remote add cryptremote gcrypt::rsync://example.com:repo
git push cryptremote master
> gcrypt: Setting up new repository
> gcrypt: Remote ID is :id:7VigUnLVYVtZx8oir34R
> [ more lines .. ]
> To gcrypt::[...]
> * [new branch]      master -> master

or under

Examples

# notice that the target git repo must already exist and its
# `next` branch will be overwritten!
git remote add gitcrypt gcrypt::git@example.com:repo#next
git push gitcrypt master

Tries

I prefer full repository encryption, hence I tried git-remote-gcrypt with variations of the Quickstart and Example. So far I tried pushing an existing repository by following their instructions. Which yields this: (note: I have purposely changed the username to user)

-> with ssh as in the provided example

[...]/git_test$ git remote add origin gcrypt::git@bitbucket.org:user/test.git
[...]/git_test$ git push -u origin --allgcrypt: Development version -- Repository format MAY CHANGE
gcrypt: Repository not found: git@bitbucket.org:user/test.git
gcrypt: Setting up new repository
gcrypt: Remote ID is :id: ...
Zähle Objekte: 10, Fertig.
Komprimiere Objekte: 100% (6/6), Fertig.
Total 10 (delta 0), reused 0 (delta 0)
gcrypt: Encrypting to: --throw-keyids --default-recipient-self
gcrypt: Requesting manifest signature
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
error: Fehler beim Versenden einiger Referenzen nach 'gcrypt::git@bitbucket.org:user/test.git'

or with https (which worked)

[...]/git_test$ git remote add gitcrypt gcrypt::https://user@bitbucket.org/user/test.git
[...]/git_test$ git push -u gitcrypt --allgcrypt: Development version -- Repository format MAY CHANGE
Password for 'https://user@bitbucket.org': 
gcrypt: Repository not found: https://user@bitbucket.org/user/test.git
gcrypt: Setting up new repository
Password for 'https://user@bitbucket.org': 
gcrypt: Remote ID is :id: ...
Zähle Objekte: 10, Fertig.
Komprimiere Objekte: 100% (6/6), Fertig.
Total 10 (delta 0), reused 0 (delta 0)
gcrypt: Encrypting to: --throw-keyids --default-recipient-self
gcrypt: Requesting manifest signature
Password for 'https://user@bitbucket.org': 
To gcrypt::https://user@bitbucket.org/user/test.git
 * [new branch]      master -> master
Branch master konfiguriert zum Folgen von Remote-Branch master von gitcrypt.

Nevertheless, I don't understand how to add users or even just pull my backup onto another machine (since my gpg key was generated locally) !? Feel free to just answer on usage of git-remote-gcrypt.

Answer 1

A free and partially open-source tool is Keybase :

Git supports remote helpers. And we've made an open source one.

Keybase's remote helper performs all the crypto while letting git do its thing. This might sound impressive, but Keybase has not reimplemented git from scratch. We provide a remote helper, powered by the excellent go-git project, which we've begun contributing to.

We bring to the table: (1) crypto, (2) team + multi-device key management, (3) a safer concept of identity.

It is end-to-end encrypted. It's hosted, like, say, GitHub, but only you (and teammates) can decrypt any of it. To Keybase, all is but a garbled mess. To you, it's a regular checkout with no extra steps.

Even your repository names and branch names are encrypted, and thus unreadable by Keybase staff or infiltrators.

Teamwork is supported via Keybase Teams :

A Keybase team is a named group of people, with flexible membership. Let's say you work on a project called Treehouse. You could register treehouse on Keybase. This team name is universal; there can be only one Keybase team with a given name.

Teams get chats and channels. The chat looks a bit like Slack or Discord:

But Keybase teamwork is end-to-end encrypted, which means you don't have to worry about server hacks.

Answer 2

Step by step instructions, using git-remote-gcrypt and Bitbucket:

Prerequisites

• GnuPG (brew install gpg on macOS)
• git-remote-gcrypt (brew install git-remote-gcrypt on macOS)

Overview

This guide will walk you through the process of creating and using a git repo called “gcrypt-sample” with Bitbucket, taking advantage of git-remote-crypt with a dedicated PGP keypair to provide end-to-end encryption.

Every push will be a force push!

Steps

Setting Up

1. Set up your local and remote repositories:
   • Set up local repository with git init gcrypt-sample
   • On bitbucket.org, create a repository gcrpyt-sample
2. Set up your ssh key if you haven’t already: ssh-keygen
3. Add a gcrypt remote: git remote add cryptremote gcrypt::git@bitbucket.org:user/gcrypt-sample.git
4. Generate your GPG keypair. Recommend this guide; for this sample, simply running gpg --gen-key will work.
5. Configure gcrypt to accept the gpg key you just created:
   1. git config remote.cryptremote.gcrypt-participants <GPG key fingerprint>
   2. git config remote.cryptremote.gcrypt-signingkey <GPG key fingerprint>
6. Edit your git repo:
   1. echo 'Hello, world!' > hello.txt
   2. git add hello.txt
   3. git commit
7. git push -u cryptremote master
   • If you have multiple PGP keypairs, you’ll have to cycle through until you get the one you want—this is because you pull before pushing, every time; see the note below.

A note about pulling from the repo

Everytime you pull down (including when you push), you will have to cycle through your PGP keys until you get to the correct one. The reason for this is that the default for git-remote-gcrypt is to use a privacy guard which redacts the identity of the signing key. Consequently, when pulling from the repository, you have to check all of your available keys to see which one is the signing key. The signing key used can be published (and therefore anonymity revoked) by setting the remote.cryptremote.gcrypt-publish-participants property (to anything).

If you set an explicit and singular PGP key for the repo, doing that should be fine. However, doing so does have implications for shared repos (different commits can be tied undeniably to different users).

What’s Encrypted?

To my naked eye, pretty much everything.

What IS encrypted

• Filenames (including paths)
• File contents
• Branches (I don’t know if the first branch pushed is logged under master, but all subsequent ones were)
• Commit history: There is a single commit (“Initial commit”) and a single date (although dates of your pushes may be tracked by your remote separately, of course—BitBucket’s “Last updated” shows the accurate time. Of course, Bitbucket’s probably not paying attention to the commits themselves—it’s probably assuming you’re doing that.)

What is NOT encrypted

• Repository name (though that’s obvious enough); just use a codename
• The number or size of files (they are not distributed in any way); not sure what the implications are for different branches

Answer 3

This can be accomplished in a decoupled way by using an actively developed user-space encrypted filesystem tool such as gocryptfs or cryptomator. The file paths are also encrypted.

gocryptfs usage

Personally I prefer gocryptfs over cryptomator because the former is a single binary and can also more easily be automated. That's even though cryptomator looks to be a more mature project.

gec is a bash utility which attempts to make it more convenient to use an encrypted gocryptfs filesystem in a git repo. At a minimum, note the -sharedstorage option which it uses with gocryptfs.

Cryptomator usage

1. Create an encrypted vault in say ~/cryptomator/encrypted/myvault1. Optionally delete the useless file IMPORTANT.rtf from this directory.
2. Run git init in the above directory containing the encrypted vault. Add one or more git remote URLs.
3. Decrypt the vault into say ~/cryptomator/decrypted/myvault1. Add or change one or more files in the unlocked vault.
4. Commit and push all changes in the git repo.