What is the current status of this issue?

• --import-options restore
  • Implies
    • import-local-sigs
    • keep-ownertrust
  • Turns off
    • import-minimal
    • import-clean
    • repair-pks-subkey-bug
    • merge-only

• --export-options backup
  • Implies
    • export-local-sigs
    • export-attributes
    • export-sensitive-revkeys
  • Turns off
    • export-clean
    • export-minimal
    • export-pka
    • export-dane
  • Causes build_packet_and_meta() to be used instead of build_packet()
    • This variant also writes the meta data using ring trust packets.
      • a8895c99a7d0
        • Ring trust packets are implementation defined and have always been used in gpg to cache the signature verification status.
        • Ring trust packets are only exported with the export option "backup" and only imported with the import option "restore".
        • As a side-effect of this patch the signature status cache works again and "gpg --check-sigs" is thus much faster.
      • RFC 4880 § 5.10
      • doc/DETAILS

Here are the patches without any new commands:

New commands can't be introduced.

New commands can't be introduced.

@werner Only patches 2 and 3 introduce new commands. What do you think about the other changes?

I also experienced this issue while testing my --delete-secret-key patches. Passing --pinentry-program /usr/bin/pinentry-tty to the gpg-agent worked around it.

Add confirmation prompt for exactly-specified public subkeys.

Add documentation.

Add documentation.

Remove gpg_ prefix from function.

Squashed: D482

Squashed: D485

Squashed: D488

A better solution has been commited: cc6069ac6ecd

@werner Thank you for resolving this issue.

Rebased on top of master: 4c7d63cd5b02

Rebased on top of master: 4c7d63cd5b02

Rebased on top of master: 4c7d63cd5b02

Rebased on top of master: 4c7d63cd5b02

Rebased on top of master: 4c7d63cd5b02

Rebased on top of master: 4c7d63cd5b02

Rebased on top of master: 4c7d63cd5b02
Add the if (okay) conditional back to the code

Rebased on top of master: 4c7d63cd5b02

Rebased on top of master: 4c7d63cd5b02

@werner Thanks for merging the --dry-run patch in 110a4550179f !

Committed to master: 110a4550179f

It appears this issue was first identified and triaged in 2016: T2879
The subkey deletion feature also showed up in other issues since then:

Diffs downloaded from the revisions don't include commit messages for some reason. Here are all the commits I submitted for review as patch files with messages:

Revision D482 adds an extra confirmation prompt before deleting the secret primary key.
Revision D483 adds portuguese translation for the primary key deletion confirmation message.

Fix missing curly brace.

@werner Here are the patches:

In T4457#124752, @matheusmoreira wrote:

I thought about building a list of keys targeted for deletion so gpg can then ask the user to confirm the deletion of each key individually.

@dkg, thanks for the feedback. I read [doc/HACKING](https://www.gnupg.org/faq/HACKING.html) and revised the commit message so that it contains ChangeLog entries and a marker line before my description. I compared my new message to prior log entries and they seem to match now. Is this appropriate? If so, I will revise my other commits in the same manner.

@dkg Sure! I thought I was supposed to email the patches to the development mailing list. [I've uploaded my delete-secret-subkey branch to GitHub.](https://github.com/matheusmoreira/gnupg/tree/delete-secret-subkey) You can see a comparison here. I'll describe my changes.

I managed to make it work on my branch: gpg --delete-secret-key FPR! deletes just that key and no others! I will prepare a patch for this specific change and then try to implement the --delete-secret-subkeys command.

I've been studying the source code. When a fingerprint suffixed with ! is given as argument, the [do_delete_key](https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=g10/delkey.c;h=cc567384612ccf0dfd41d9e620d6cd5e759fd7b6;hb=HEAD#l50) function correctly classifies the search descriptor as exact and finds the correct key using [keydb_search](https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=g10/keydb.c;h=8c067e1dfbfa7a6394e44dbed3bfaef5a4fa7c43;hb=HEAD#l1853). However, the handle returned by [keydb_get_keyblock](https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=g10/keydb.c;h=8c067e1dfbfa7a6394e44dbed3bfaef5a4fa7c43;hb=HEAD#l1352) apparently includes the primary key and all subkeys associated with it. After confirming the action with the user, the function iterates over all PKT_PUBLIC_KEY and PKT_PUBLIC_SUBKEY packets present in the keyblock, obtains the keygrip of each key and asks gpg-agent to delete it.