Page MenuHome GnuPG
Create Task
Maniphest T1817

Changing expiration on subkeys breaks subkeys
Closed, ResolvedPublic
Actions

Description

I'm using relatively short-lived subkeys that I change expiration of once in a
while. Apparently, doing this damages your subkey secret keyring.

This came up when testing OpenPGP keychain, see my bug report:

https://github.com/open-keychain/open-keychain/issues/1026

which refers to another bug of theirs:

https://github.com/open-keychain/open-keychain/issues/996

which says that GnuPG 2.1 fixes this. That's good. However, I just tested it
in GnuPG 1.4.18 and 2.0.26 and it does not work. I don't have GnuPG 2.1 on that
machine, so I couldn't confirm that it is fixed in 2.1. This is a request to
fix it in 1.4 and 2.0 if doing so is feasible.

The recipe to reproduce this is simple but a bit time-consuming:

  1. Create a key with some subkeys.
  2. Display it with gpg --export-secret-keys DEADBEEF | gpg --list-packets
  3. Change expiration date of the subkeys.
  4. Again display it.

Compare the outputs and note that the keyflags of the signature subkey has
changed from 02 to 20 and that the signature is gone.

Details

Version
1.4.18, 2.0.26

Event Timeline

jas added projects: gnupg, Bug Report.Jan 15 2015, 10:23 PM
jas set Version to 1.4.18 & 2.0.26.
jas added a subscriber: jas.
• werner added a project: Won't Fix.Jan 19 2015, 4:55 PM
• werner added a subscriber: • werner.

It is known that the secret keyrings easily gets out of sync. Thus do not rely
on that information. Always use the public key ring for such info.

We won't fix that in < 2.1

• werner added a comment.Jan 27 2015, 9:08 AM

I just verified that it is not a problem in 2.1.

I am not sure whether it makes sense to fix it in 1.4 given that it is easier to
change it with 2.1, export and import it then to 1.4. I feel it is better to
use my time to fix some missing export options in 2.1

• werner removed a project: Won't Fix.Jan 27 2015, 9:09 AM
• werner added projects: maybe, gnupg (gpg14).
• werner added a project: Stalled.
jas added a comment.Jan 27 2015, 11:54 AM

What's not clear to me if it is possible to recover a private key that is
damaged this way? If you change expiration with 1.4, the self-signatures are
lost and some key flags are changed. Is it possible to recover from that? That
is the problem I'm concerned with -- if it isn't possible to recover, it seems
people end up with damaged secret subkeys after changing expiration date on a
subkey with gnupg 1.4/2.0.

• werner added a comment.Jan 27 2015, 12:27 PM

But the secret subkeys are not used. Or well, the keyflags should be taken from
the public key. That might not always be the case - in particular not if you
re-create the public key from the secret key.

You can of course repair it using 2.1 because there --export-secret-key takes
the public key and only adds the secret parameters.

bernhard closed this task as Resolved.Dec 9 2015, 3:55 PM
bernhard claimed this task.
bernhard added projects: gnupg (gpg20), Won't Fix.

Some more infos:

https://www.openkeychain.org/faq/#importing-your-own-key-from-gnupg-fails
says that this is a problem for a number of people.

Werner told me that porting the fix back would mean to basically
migrate 2.0 to 2.1, which is useless because 2.1 is already 2.1.

Another possibility would be to change --export to mix public keys (certs)
with secret keys. This would create other problems and thus is not
adviable for a stable version.

So I think this is "won't fix" because it (technically) does not make
sense to fix in 1.4 or 2.0. Solutions: Use 2.1 or wait for 2.2.
As importing implementation: Be tolerant for this problem man use the cert
information if you can.

bernhard changed Version from 1.4.18 & 2.0.26 to 1.4.18, 2.0.26.Dec 9 2015, 3:55 PM
bernhard removed projects: Stalled, maybe.