Open xxxserxxx opened 3 years ago
Yeah the command line client is in keys-pub/keys-ext/service and we could add a subcommand: keys gpg ...
, that mimics the gpg command line arguments?
That would certainly be cleaner and easier for most people than installing another utility wrapper. Can we handle cases where the only configurable option is what the binary is called, or would that be too invasive? Like, checking if os.Args[0]
was keysgpg
and (internally) calling the gpg mock function? In extreme cases, where users can only tell the mail client where the GPG executable is, they could at least symlink keys
to keysgpg
and then configure the executable to that.
Many (email) clients have some support for GNUpg (e.g., astroid). While some may allow complex configuration sufficient to hand-code swapping in
keys-pub
, for some the integration is hard-coded. In these cases, it'd be useful to have a wrapper script that mocks GNUpg for signing, verification, decryption, and encryption.Arguments for providing a utility script, and including it in the
keys-pub/keys
(or, possibly,keys-pub/keys-ext
) are:I'm willing to provide a pull request, but I believe the resulting code would be best hosted in the canonical repo, and having input from users of other email clients would help nail a more robust implementation.