Encrypt every ref and object into a "new" repository

[chmac]

Following this comment I'm breaking this out into a separate issue.

Idea: Encrypt each ref and object from the source repo as a file in the encrypted repo

When pushing the unencrypted repo:

• Create .git/encrypted
  • cd .git/encrypted && git init && git remote add ... && cd ../..
• Encrypt the output of git show-ref
  • Save this into .git/encrypted/refs
• Iterate over each ref and recursively over every linked object
  • Encrypt the output of git cat-file $ref
  • Save this into .git/encrypted/objects/xx/xx/xxxx
• Add a commit with all changes from above inside .git/encrypted
  • cd .git/encrypted && git add . && git commit -m updates && git push

Pulling an encrypted repo would then look like:

• Create .git/encrypted
  • cd .git/encrypted && git init && git remote add ... && git pull
• Iterate over every object
  • find objects/ -type f
  • Decrypt the object
  • Copy the object into the parent git object store
• Decrypt .git/encrypted/refs and recreate the refs

[chmac]

Question: Where do we store the keys?

To start with we could use a single key and symmetric encryption. This won't be ideal, but is likely the simplest option to get started. I guess we could learn a lot from git-crypt in this regard. We could store some additional metadata in the .git/encrypted folder like .git/encrypted/meta which is also encrypted.

For simplicity, I'd guess we supply the encryption key externally. We assume that we have 2 commands / functions that we can call simply encrypt() and decrypt() and they are instantiated with all the info they need.

[chmac]

Thinking about how this would work on top of isomorphic-git.

Walking every object might be tricky. Also, there are probably optimisations possible, but let's think about that later.

• First get all branches and tags
  • listRemotes() then for each remote listBranches()
  • listBranches()
  • listTags()
  • Maybe we can skip tags if we assume that all tags are also in the commit history? Sounds tricky.
• Then for each branch / tag
  • log()
• Then for each commit
  • walk(TREE({ ref }))

[vHanda]

Question: Where do we store the keys?

To start with we could use a single key and symmetric encryption. This won't be ideal, but is likely the simplest option to get started. I guess we could learn a lot from git-crypt in this regard. We could store some additional metadata in the .git/encrypted folder like .git/encrypted/meta which is also encrypted.

This is a more central question for me - What kind of encryption do you use, and how do you store the keys.

This is relevant in the case when you want to push some encrypted files to a remote which doesn't handle encryption. Say I have a file hello.txt -> I can encrypt it -> hello.txt.enc, and push it to the remote. My local git client should transparently handle the encryption / decryption and reading of the history of the file.

If we can come up with a standard on how to define which encryption scheme is used, and where they keys can be fetched from, this becomes something everyone can implement. I'm imagining GitJournal implementing it, and even having a vscode extension for this.

[chmac]

@vHanda I think this is how git-crypt works. It uses the smudge / clean filters to encrypt the contents of some files in a repository. Then the filenames, the commit history, the directory names, and so on, are all transparent to the host. My thinking in this issue is to encrypt every object and save those encrypted objects as normal "files" in a new git repository. It's like git inside git. That's how git-remote-gcrypt works, although because it encrypts the whole repo in a single step, there are some drawbacks.