-
Notifications
You must be signed in to change notification settings - Fork 1
Description
I just saw that GnuPG 2.1.15 stores its secret keys in a different location: ~/.gnupg/private-keys-v1.d/*.key
The old GnuPG (1.x, maybe even including 2.0.x) stored the secret keys in: ~/.gnupg/secring.gpg
When upgrading from GnuPG 1.x to 2.x, the secret keys are automatically migrated and the file ~/.gnupg/.gpg-v21-migrated is created. If a new key pair is generated afterwards using subshare or GnuPG 1.x, GnuPG 2.x does not migrate the secret key anymore! It lists the new public key correctly (because it's still using the ~/.gnupg/pubring.gpg) but does not know the private key exists!
Btw. it is possible as a workaround, though, to delete the file ~/.gnupg/.gpg-v21-migrated -- GnuPG 2.x then migrates the secret keys again.
Also, when GnuPG 2.x creates a new secret key pair, the ~/.gnupg/secring.gpg is not modified. The new secret key is only created inside ~/.gnupg/private-keys-v1.d/. If GnuPG 1.x is used later, again, it thus doesn't see the new secret key.
Subshare should be extended to detect whether the GnuPG 2.x is used and should then read the secret keys from the new sub-directory! Also when creating new key pairs, it should write them into the new sub-directory.
But Subshare should still be compatible with GnuPG 1.x, too!!! Thus, if GnuPG 2.x is not used, Subshare should work exactly like it's doing now.
Maybe, subshare should even check, if the old ~/.gnupg/secring.gpg still exists and make sure that the data for both GnuPG 1.x and 2.x are complete and correct (in case a user uses both systems -- AFAIK, it is possible to install and use both at the same time).