I had some revoked subkeys that I was not going to use anymore.
I thought it would be a good idea to delete their secret keys,
so I used the gpg --delete-secret-keys command to do it.
I ended up accidentally deleting all my keys instead,
including my primary key.
I'm trying to learn from my mistake but I don't understand how or why
this happened.
I was able to reproduce what I did.
First, I generated a primary key and a subkey:
$ gpg --batch --passphrase '' --quick-generate-key 'test key' rsa4096 cert 0
# Generated primary key D7D79C32883EA862C586881DA52099E0E7EB77A5
$ gpg --batch --passphrase '' \
--quick-add-key D7D79C32883EA862C586881DA52099E0E7EB77A5 \
rsa4096 sign 0
$ gpg --list-keys
pub rsa4096/0xA52099E0E7EB77A5 2019-04-10 [C]
Key fingerprint = D7D7 9C32 883E A862 C586 881D A520 99E0 E7EB 77A5
uid [ultimate] test key
sub rsa4096/0x20AA2F4F7A28CD01 2019-04-10 [S]
Key fingerprint = 9CAE 802D A78E 4624 BD8F 88FE 20AA 2F4F 7A28 CD01
Having generated a primary key and subkey,
I asked gpg to delete the subkey by specifying its fingerprint.
However, instead of operating on the specified subkey,
gpg asked me to confirm the deletion of the primary key!
$ gpg --delete-secret-keys 9CAE802DA78E4624BD8F88FE20AA2F4F7A28CD01
sec rsa4096/0xA52099E0E7EB77A5 2019-04-10 test key
Delete this key from the keyring? (y/N)
I admit that I failed to check the fingerprint reported by gpg
before confirming all three prompts, including a graphical pop-up.
However, I did double check the fingerprint I gave as argument.
In my understanding, the program decided to operate on a different key.
I specified the subkey but it acted as if I had given the primary key instead.
It was suggested that I append an exclamation mark to the fingerprint.
Indeed, the manual does seem to support this suggestion:
> an exclamation mark (!) may be appended
> to force using the specified primary or secondary key
> and not to try and calculate which primary or secondary key to use.
When I tried it with new keys, it did not seem to have any effect.
$ gpg --delete-secret-keys 5B139477AE36C2F5D03C29E6920FD2FB0019253E!
sec rsa4096/0x8A1C31D584422F7A 2019-04-10 test key
Delete this key from the keyring? (y/N)
gpg still tried to delete the primary key instead of the specified subkey.
It was also suggested that I use the subkey's ID instead of the fingerprint.
I generated new keys, tried it and it did not work either.
$ gpg --delete-secret-keys 8395C88AD6549DEE
sec rsa4096/0x076968E9FF7991BC 2019-04-10 test key
Delete this key from the keyring? (y/N)
$ gpg --delete-secret-keys 8395C88AD6549DEE!
sec rsa4096/0x076968E9FF7991BC 2019-04-10 test key
Delete this key from the keyring? (y/N)
gpg always deletes the primary key and all subkeys,
no matter what input I give it.
I am using GNU Privacy Guard 2.2.15 on Arch Linux x86_64.
I don't want to make this kind of mistake again.
Am I using the program correctly? If not, what is the correct way to do this?
Is deleting subkeys something I am not supposed to do?
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
