https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/ or "sop" is a standard for a command-line interface for OpenPGP. There are several implementations available in Debian already, like sqop (using Sequoia), gosop, gpainless-cli, and hop from hopenpgp-tools (haskell).
It's possible to use this in a way that interoperates with gpg. For example:
joey@darkstar:~>cat pw
hunter1
joey@darkstar:~>cat foo
Tue Jan 9 15:10:32 JEST 2024
joey@darkstar:~>sqop encrypt --with-password=pw < foo > bar
joey@darkstar:~>gpg --passphrase-file pw --decrypt bar
gpg: AES256.CFB encrypted session key
gpg: encrypted with 1 passphrase
Tue Jan 9 15:10:32 JEST 2024
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 compatible 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
and use them with sop to encrypt/decrypt files, it wouldn't make sense
for git-annex to do that for the user. So there would need to be some way
to map from keyid= value to a file containing the key. Which could be as
simple as files named .git/annex/sop/$keyid.sec
, which would be installed
by the user using whatever means they prefer.
Since sop also supports hardware-backed secret keys, and using one avoids
the problem of where to store the secret key file, it would be good to
support using those. This could be something like keyid=@HARDWARE:xxx
making @HARDWARE:xxx
be passed to sop.
It seems that git-annex would need to prompt for the secret key's password
itself, since sop doesn't prompt, and feed it in via --with-key-password
.
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
See also: whishlist: GPG alternatives like AGE