Skip to content

Support GnuPG 2.x #49

@nlmarco

Description

@nlmarco

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).

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions