Nope

Here are the patches without any new commands:

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

In case I not already mentioned it: There won't be any new commands to delete a key. Of course you are free to change GnuPG as you like but I won't apply them here.

@werner Thank you for resolving this issue.

See the man page on how to delete subkeys or just the primary secret key with --delete-key.

Actually I have a different approach to fix this bug(let). Please give me a few days.

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

In master, I pushed a change, closing.

For future, it would make sense applying your patch, but I wonder if it works on macOS.
Let me check.

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

Without -no-undefined, libtool refuses to create the shared library (dll) on Cygwin, because libtool knows that creating a shared library (dll) on Cygwin does require all symbols to be defined.
Unfortunately but traditionally, by default libtool has to assume a library being created will have undefined symbols.
Hence, if the library to be created is designed to have all symbols defined, libtool needs to be informed about this fact using the -no-undefined flag.
This flag does allow libtool to create a shared library even on platforms known to require all symbols to be defined for shared libraries.

Please explain in more detail what the problem with Cygwin is.

I've applied your patch with an additional comment to our master branch. Thanks!

We do not support 64 bit Windows thus this problem on Cygwin is obvious. Funny that Cygwin falls back to native Windows object in this case.

Sorry, this did not make it into 3.1.6. But I'll definitely see about it for the next release. If it is an institutional / corporate issue you could also contract us through www.gnupg.com

From: aheinecke (Andre Heinecke)
Sent: Montag, 28. Januar 2019 19:25

fwiw. Your patch is beautiful in which it follows our coding style and
debug output. I'm confident that we will accept it but currently I have
to read up on Job's a bit.

Is there a way I could help you with this? This issue is hampering adoption
of GnuPG 2 here.

--

Jan Echternach

Patch applied, thanks.

Patch applied, thanks.

fwiw. Your patch is beautiful in which it follows our coding style and debug output. I'm confident that we will accept it but currently I have to read up on Job's a bit.

That is a very interesting problem that we did not have on our radar.