Title Changing expiration on subkeys breaks subkeys
Priority bug Status resolved
Category gnupg Due Date
Version 1.4.18, 2.0.26 ExtLink  (go)
Superseder Nosy List jas
Assigned To Topics gpg14, gpg20, wontfix  (help)

Created on 2015-01-15.21:23:54 by jas, last changed 2015-12-09.14:55:27 by bernhard.

msg7522 (view) Author: bernhard Date: 2015-12-09.14:55:27
Some more infos:
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.
msg5786 (view) Author: werner Date: 2015-01-27.11:27:10
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.
msg5785 (view) Author: jas Date: 2015-01-27.10:54:20
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.
msg5784 (view) Author: werner Date: 2015-01-27.08:08:25
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
msg5759 (view) Author: werner Date: 2015-01-19.15:55:20
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
msg5755 (view) Author: jas Date: 2015-01-15.21:23:54
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:

which refers to another bug of theirs:

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.
Date User Action Args
2015-12-09 14:55:27bernhardsetstatus: deferred -> resolved
topic: + wontfix, gpg20, - maybe
version: 1.4.18 & 2.0.26 -> 1.4.18, 2.0.26
messages: + msg7522
2015-01-27 11:27:11wernersetmessages: + msg5786
2015-01-27 10:54:20jassetmessages: + msg5785
2015-01-27 08:09:26wernersetstatus: chatting -> deferred
2015-01-27 08:09:15wernersettopic: + gpg14, maybe, - wontfix
2015-01-27 08:08:26wernersetmessages: + msg5784
2015-01-19 15:55:20wernersettopic: + wontfix
status: unread -> chatting
messages: + msg5759
2015-01-15 21:23:54jascreate