This issue is to track discussion around git-remote-gcrypt and if we could achieve interop with its encryption format.
Having dug into the code, read the docs, and run some local tests, I think it works like this:
The git objects and pack files get encrypted
Their encrypted filename is the hash of their contents
The keys to encrypt those files are put into a "manifest" file
This file is always called 91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a
The encrypted pack file, object files, maybe some others, and the manifest are put into a directory
This directory is then converted into a git repository with a single commit
Put differently, if you push this repo to something like GitHub you get a repo with a single commit, with a fixed, hardcoded commit author, time, and a list of files which are the encrypted contents
There is no commit history visible, and only one commit
Effectively, a git hosting service is used as a store of the latest "encrypted" git repository. So any pushes must upload the whole commit history again, because from GitHub's perspective, there's only ever 1 single commit.
Pros
Strong privacy, not much info is leaked
Not even commit history, frequency, etc, is leaked
Long standing codebase that's probably been well tested
Cons
Brutal uploads for each push, especially harsh on mobile
chmac
commented
3 years ago
This issue is to track discussion around git-remote-gcrypt and if we could achieve interop with its encryption format.
Having dug into the code, read the docs, and run some local tests, I think it works like this:
91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0aEffectively, a git hosting service is used as a store of the latest "encrypted" git repository. So any pushes must upload the whole commit history again, because from GitHub's perspective, there's only ever 1 single commit.
Pros
Cons