Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support GnuPG 2.x #49

Open
nlmarco opened this issue Mar 29, 2017 · 3 comments
Assignees
Labels

Comments

@nlmarco
Copy link
Contributor

@nlmarco nlmarco commented Mar 29, 2017

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

@nlmarco nlmarco added the enhancement label Mar 29, 2017
@nlmarco nlmarco added this to the 0.10.0 milestone Mar 29, 2017
@nlmarco nlmarco self-assigned this Mar 29, 2017
@nlmarco

This comment has been minimized.

Copy link
Contributor Author

@nlmarco nlmarco commented Mar 29, 2017

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

@nlmarco

This comment has been minimized.

Copy link
Contributor Author

@nlmarco nlmarco commented Apr 1, 2017

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.

@nlmarco nlmarco modified the milestones: 0.10.1, 0.10.0 Apr 1, 2017
nlmarco added a commit that referenced this issue Apr 1, 2017
@nlmarco

This comment has been minimized.

Copy link
Contributor Author

@nlmarco nlmarco commented Apr 1, 2017

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.

@nlmarco nlmarco modified the milestones: 0.10.1, 0.10.3 Sep 21, 2017
@nlmarco nlmarco removed this from the 0.10.3 milestone Oct 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.