mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

support annex.shared-sop-command for encryption=shared

Browse source 
This works well, and it interoperates with gpg in my testing (although some
SOP commands might choose to use a profile that does not so caveat emptor).

Note that for creating the Cipher, gpg --gen-random is still used. SOP
does not have an eqivilant, and as long as the user has gpg around,
which seems likely, it doesn't matter that it uses gpg here, it's not being
used for encryption. That seemed better than implementing a second way
to get high quality entropy, at least for now.

The need for the sop command to run in an empty directory has each call
to encrypt and decrypt creating a new temporary directory. That is some
unncessary overhead, though probably swamped by the overhead of running
the sop command. This could be improved in the future by passing an
already empty directory to them, or a sufficiently empty directory
(.git/annex/tmp would probably suffice).

Sponsored-by: Brett Eisenberg on Patreon
This commit is contained in:
Joey Hess 2024-01-12 13:29:34 -04:00
parent dd3e779020
commit 7e69063a29
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
7 changed files with 116 additions and 68 deletions
Download patch file Download diff file Expand all files Collapse all files

20
doc/todo/support_using_Stateless_OpenPGP_instead_of_gpg.mdwn
View file

@ -19,6 +19,14 @@ That example uses symmetric encryption, which is what git-annex uses
for encryption=shared. So git-annex could use this or gpg to access the
same encrypted special remote.
Update: That's implemented now, when annex.shared-sop-command is configured
it will be used for encryption=shared special remotes. It interoperates
fine with using gpg, as long as the sop command uses a compatable profile
(setting annex.shared-sop-profile = rfc4880 is probably a good idea).
Leaving this todo open because there are other encryption schemes than
encryption=shared, for which using sop is not yet supported.
For the public key encryption used by the other encryption= schemes,
sop would be harder to use, because it does not define any location
to store private keys. Though it is possible to export gpg private keys
@ -39,14 +47,6 @@ It can detect if a password is needed by trying the sop operation without a
password and checking for an exit code of 67.
See [this issue on sop password prompting](https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/64)
git-annex also uses gpg to generate random data for an encryption cipher
when setting up an encrypted special remote. Of course there are other ways
to generate random data, but it does make sense to use gpg or a similar
tool for this particular random data generation, since it's effectively a
secret key. And genRandom already using --armor. So when using sop, it
seems like it might make sense to use the `generate-key` command, and
extract the armored data from it. Although note that not all of that output
is random, the first several bytes are OpenPGP header that doesn't change
much.
See also: [[todo/whishlist__58___GPG_alternatives_like_AGE]]
[[!meta title="support using Stateless OpenPGP instead of gpg for encryption methods other than encryption=shared"]]