This is my current understanding on how one must use gpg with git-annex:
- Generate(or copy around) a gpg key on every machine that needs to access the encrypted remote.
- git annex initremote myremote encryption=KEY for each key that you generated
What I'm trying to figure out is if I can generate a no-passphrase gpg key and commit it to the repository, and have git-annex use that. That way any new clones of the annex automatically have access to any encrypted remotes, without having to do any key management.
I think I can generate a no-passphrase key, but then I still have to manually copy it around to each machine.
I'm not a huge gpg user so part of this is me wanting to avoid having to manage and keeping track of the keys. This would probably be a non-issue if I used gpg on more machines and was more comfortable with it.
Thinking about this more, I think minimally git-annex could support a
or
for options to be passed to gpg. I'm not sure how automatically setting it to $ANNEX_ROOT/.gnupg/.. would work.
I need to read the encryption code to fully understand it, but I also wonder if there is not also a way to just bypass gpg entirely and store the remote-encryption keys locally in plain text.
The encryption uses a symmetric cipher that is stored in the git repository already. It's just stored encrypted to the various gpg keys that have been configured to use it. It would certianly be possible to store the symmetric cipher unencrypted in the git repo.
I don't see your idea of gpg-options saving any work. It would still require you to do key distribution and run commands in each repo to set it up.
I got a good laugh out of it :-)
Storing the key unencrypted would make things easier.. I think at least for my use-cases I don't require another layer of protection on top of the ssh keys that provide access to the encrypted remotes themselves.