Open nlmarco opened 7 years ago
According to http://stackoverflow.com/questions/34212230/using-bouncycastle-with-gnupg-2-1s-pubring-kbx-file the public keys are stored in a different file format, too, by default. However, GnuPG 2.1 continues to use the old ~/.gnupg/pubring.gpg
in a compatibility-mode, if this old file exists (and the new one doesn't).
I asked on the dev-crypto mailing-list and the BC team said that the new file formats are on their to-do list. But they don't know, yet, when they are going to be supported. Definitely, they are not yet supported, right now.
This issue thus needs to be postponed.
As a temporary workaround, I added the deletion of the file ~/.gnupg/.gpg-v21-migrated
, whenever a new secret key is imported (or created). This way, at least new secret keys generated by subshare should become visible in GnuPG 2.1.
This is included in subshare 0.10.0. A proper solution is coming later, when a new BouncyCastle supports the new GPG 2.1 file formats.
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).