gpg wants to delete my master key when I'm trying to delete a subkey?
Open, Needs TriagePublic


After using the addkey function within a script, trying to delete the subkey results in the master key deletion.
The two key are generated outside GPG inside a Tokn , extracted and imported inside GPG.

The extract fom the script that uses the addkey function is the following :

expect << EOF
spawn bash -c "{ echo addkey; echo 13; echo Q; echo 0; echo save; } | gpg -v --debug-level 2 --no-use-agent --command-fd=0 --status-fd=1 --pinentry-mode=loopback --expert --passphrase-file <(echo $PASSWORD) --edit-key $KEY_MAST"
expect "Enter the keygrip: " { send "$KEYRING_SUBKEY\r" }
expect eof

It gives the following results :
sec rsa1024 2020-09-18 [SC]

Keygrip = 36A8042BFF5FB47B9F36AF28D04EB801A3440B8F

uid [ultimate] master (comment) <email>
ssb rsa1024 2020-09-18 [SE]

Keygrip = D877DCDFCB62146D910B85E8830ACE62A3A82EC2

sec rsa1024 2020-09-18 [SC]

Keygrip = D877DCDFCB62146D910B85E8830ACE62A3A82EC2

uid [ultimate] subkey (comment) <email>

The command : "gpg --delete-secret-and-public-keys subkey", results in a message asking confirmation for the deletion of the master key.

This might be a bug in GPG, as sometimes after several execution of the script in a row, the subkey seems to be added correctly and the deletion message correspond to the one of the subkey.


moria created this task.Sep 21 2020, 7:42 AM
moria created this object in space S1 Public.
werner added a subscriber: werner.Sep 21 2020, 9:05 AM

Please do not use addkey with in such a way. The use of "canned"commands way work now for you but can lead to unexpected results if anything changes, either due to changes in another gpg version or due to changes in your key etc.. The correct use requires a state machines along with --stattus-fd and command-fd. Because that is quite hairy to get right we have added a set of quick commands. In your case your should use

--quick-add-key fpr [algo [usage [expire]]]

  Directly add a subkey to the key identified by the
  fingerprint fpr.  Without the optional argu‐ ments an
  encryption subkey is added.  If any of the arguments are
  given a more specific subkey is added.

  algo may be any of the supported algorithms or curve names
  given in the format as used by key listings.  To use the
  default algorithm the string ``default'' or ``-'' can be
  used.  Supported algorithms are ``rsa'', ``dsa'', ``elg'',
  ``ed25519'', ``cv25519'', and other ECC curves.  For ex‐
  ample the string ``rsa'' adds an RSA key with the default key
  length; a string ``rsa4096'' re‐ quests that the key length
  is 4096 bits.  The string ``future-default'' is an alias for
  the algo‐ rithm which will likely be used as default
  algorithm in future versions of gpg.  To list the sup‐ ported
  ECC curves the command gpg --with-colons --list-config curve
  can be used.

  Depending on the given algo the subkey may either be an
  encryption subkey or a signing subkey.  If an algorithm is
  capable of signing and encryption and such a subkey is
  desired, a usage string must be given.  This string is either
  ``default'' or ``-'' to keep the default or a comma delim‐
  ited list (or space delimited list) of keywords: ``sign'' for
  a signing subkey, ``auth'' for an authentication subkey, and
  ``encr'' for an encryption subkey (``encrypt'' can be used as
  alias for ``encr'').  The valid combinations depend on the

  The expire argument can be used to specify an expiration date
  for the key.  Several formats are supported; commonly the ISO
  formats ``YYYY-MM-DD'' or ``YYYYMMDDThhmmss'' are used.  To
  make the key expire in N seconds, N days, N weeks, N months,
  or N years use ``seconds=N'', ``Nd'', ``Nw'', ``Nm'', or
  ``Ny'' respectively.  Not specifying a value, or using ``-''
  results in a key expiring in a reasonable default interval.
  The values ``never'', ``none'' can be used for no expiration

Back to the actual problem: From the output I can't immediatley figure out why the master key will be revoked. There is not enough information. A "gpg -k --with-keygrip USERID" along with a transcript of the delete-secret-and-public key command might be more helpful. Always add -v to the commands for more verbose diagnostics.

You can drop --no-use-agent - it has no effect.

moria added a comment.EditedSep 21 2020, 9:55 AM

Thank you very much for your answer.
Unfortunately, I can't use --quick-add-key, because I believe the command generates a new subkey. What I'm trying to do is adding an already existing key as the subkey of a master key.

Here are the results, of the command you asked :

$gpg -v --with-keygrip -k
sec   rsa1024 2020-09-21 [SC]
      Keygrip = 8E4C9F38BE3D5A9F1B2BDEF0EB92FF1B9038E447
uid           [ultimate] master (comment) <email>
ssb   rsa1024 2020-09-21 [SE]
      Keygrip = 4FEBEA1FF8AA5DEA8D4D51B22C8DCC8DD079C023

sec   rsa1024 2020-09-21 [SC]
      Keygrip = 4FEBEA1FF8AA5DEA8D4D51B22C8DCC8DD079C023
uid           [ultimate] subkey (comment) <email>

gpg --delete-secret-and-public subkey
gpg: using subkey 4F723A0B275237C7 instead of primary key 69170D09E23F7199

sec  rsa1024/4F723A0B275237C7 2020-09-21 master (comment) <email>

Delete this key from the keyring? (y/N) y
This is a secret key! - really delete? (y/N) y
gpg: pinentry launched (8435 curses 1.1.0 /dev/tty1 xterm-256color -)
pub  rsa1024/4F723A0B275237C7 2020-09-21 master (comment) <email>

Delete this key from the keyring? (y/N) y
gpg: using pgp trust model
gpg: ownertrust information cleared

Instead of using the pevious script, I tried, using a configuration file with the following options :

Key-Grip: <The Master Key-Grip>
Subkey-grip: <The Subkey Key-Grip>

Unfortunatly, It didn't add any subkey to my master key (and -v option doesn't show anything).