Wed, Mar 29
works in 3.1.27.0-beta44
Tue, Mar 28
Mon, Mar 27
Tue, Mar 21
We need to extend dirmngr_ldap.c to take a list of attributes to return. We already have the --multi option which returns all attributes for latter filtering by the caller but the specified attr is also used and thus dirmngr's start_cacert_fetch_ldap() retruns only the requested caCertificate.
Things for 2.4 are all done.
For 2.2 we will for now only implement the encryption.
Thu, Mar 16
Wed, Mar 15
Tue, Mar 14
Fixed in 2.2 need to check 2.4
Ooops. We do not have the automatic chnage of key type in the WRITEKEY command of scdaemon. This is only done when generating a key.
I agree. Something called READ... shouldn't change existing data. (Updating existing data to a new format that doesn't alter the semantics of the existing data is okay.)
Ignoring the error seems to be the best choice. I also think that --force should not overwrite a shadow key file. It seems safer to explicitly delete the key first. A --force option for READKEY does not sound right.
I did some reworking and the outcome of the READKEY command is now (agent log):
Mon, Mar 13
I am pretty sure we have the same problem in 2.4 - due to different access patterns it might not exhibit itself.
Sun, Mar 12
Pushed to this site. Thanks for noting.
Sat, Mar 11
I think this is still missing a tag in git (I don't see it in https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=tags)
Fri, Mar 10
I've run into a variant of this, too. If I generate they key just using (genkey (ecc (curve "Ed25519"))). One needs to use (genkey (ecc (curve "Ed25519")(flags eddsa)))
Mon, Mar 6
If agent_write_shadow_key does now also check for an existing private key file, then I'd replace following code in cmd_readkey:
if (agent_key_available (grip)) { /* Shadow-key is not available in our key storage. */ rc = agent_write_shadow_key (0, grip, serialno, keyid, pkbuf, 0, dispserialno); } else { /* Shadow-key is available in our key storage but ne check * whether we need to update it with a new display-s/n or * whatever. */ rc = agent_write_shadow_key (1, grip, serialno, keyid, pkbuf, 0, dispserialno); }
with a simple call of agent_write_shadow_key (removing the maybe_update flag) and let agent_write_shadow_key do all checking for an already existing private key file and whether it's a stub file that needs updating.
I think we should make it explicit - this will be safer. As of now agent_write_shadow_key will do a check only in its special update mode which should be okay for now.
I can't see any explicit thing there.
Fri, Mar 3
Make sure that the fix doesn't break "gpg --edit-key; keytocard; save" which explicitly does replace the private key with a stub file.
I doubt that the bug is only in 2.2. The code in 2.4 is different but it may happen there anyway. It depends on the usage pattern.
Thu, Mar 2
Mar 1 2023
Feb 28 2023
FWIW:The assuan keytocard does not move the key - what you see is a side effect from unrelated code.
Since I have closed T6377 which had high priority I am assigning this issue the same prio. Which I also think is appropriate.
I thought about this related to T6386 and I now agree with @ikloecker KEYTOCARD in SCD may not "move" the key. Otherwise it would be impossible to easily transfer a key to multiple smartcards. Since werner agreed in T6486 that this is a Bug and Unintended it can be closed as a duplicate as we do not need to further discuss this.
Feb 27 2023
Thanks for the report; the regression happened due to fixing T6135.
Feb 24 2023
I should probably add that Kleopatra calls this command when reading a smart card to create the key stubs if necessary. Kleopatra does this since gpg4win-3.1.24 (according to the tags) and the KDE Gear 22.04 release (see T5782: Kleopatra: Smartcard unusable secret key until used via command line).
I have analyzed the problem. It is caused by a serious regression in gpg 2.2: https://dev.gnupg.org/T6386
Feb 22 2023
Well it makes sense to me in that KEYTOCARD explicitly is not documented but the semantics between keytocard in edit key and KEYTOCARD in agent should be the same IMO. As you can imagine I am also not a fan of the fact that GnuPG changed behavior here, but the "keep / delete" is even with GnuPG 2.3 not really an option as GnuPG might replace the real key with the stub depending on how it is called anyhow. So this is dangerous for us to "suggest" from the UI that the key will be kept and then it might be removed without actions by Kleopatra. So this must be changed.
Arguing with the documentation of a functionality Kleopatra doesn't make use of makes no sense. Kleopatra uses gpg-agent's "KEYTOCARD" command which, unfortunately, lacks a good documentation.
So as I understand this: