AFAIK we don't have support for this yet in GPGME.
Description
Revisions and Commits
Status | Assigned | Task | ||
---|---|---|---|---|
Testing | • TobiasFella | T6874 Kleopatra subkey management improvements | ||
Testing | • TobiasFella | T6879 Kleopatra: Add support for adding an ADSK | ||
Testing | • TobiasFella | T6880 GPGME (++/qt): Add support for --quick-add-adsk |
Event Timeline
Before adding code please first come up with a description of the planned API extension.
For the similar task to add an existing subkey to a key we have GpgAddExistingSubkeyEditInteractor. This uses the much more complicated gpg --edit-key interface. Maybe we want to avoid this.
--quick-addkey is used by one of the modes of gpg_genkey. One option would be to extend gpg_genkey with another mode for --quick-add-adsk. And then using either gpgme_op_createsubkey or gpgme_op_createkey from the existing API by finding a creative way to pass the adskfpr to these functions, e.g. via another context variable. The internal _gpgme_engine_op_genkey can easily be extended to pass the fpr directly.
My concept would be to:
- add a GENKEY_EXTRAFLAG_ADDADSK for _gpgme_engine_op_genkey and gpg_genkey (or do that more implicitely, e.g., by detecting !USERID && KEY && PUBKEY) and pass the subkey fingerprint in pubkey
- use gpgme_op_createsubkey; pass the adsk fingerprint in a new variable in context
In the C++/Qt parts:
I think we then don't really *need* anything, since we can just set the fingerprint in the context for the job, but it would make sense to introduce a function that wraps this into a nice API.
I would use ALGO of gpgme_createsubkey to pass the fingerprint of the ADSK. This can be justified because the algorithm is an implict property of the fingerprint. Obviously we also nee a new flag to do switch to this behaviour. A new GPGME_CREATE_ADSK comes to mind.
gpg 2.4 now returns ERROR status lines for failed --quick-add-subkey and --quick-add-adsk.