Okay, that was easy to check.

@gniibe, will you be so kind an check the provided patches

gpg --edit-key; keytocard; save

work as expected.

works

gpg_encrypt (engine-gpg.c) passes --output - to gpg, i.e. it reads the result of gpg --encrypt from stdout unless I misread this. Not sure, why this seems to work on Windows. The real problem is probably something completely different.

On Windows we always use --status-fd=1 but with gpg it is not a problem because we use a differenrt fd for output.

The gpgme logs show that gpgtar is called with gpgtar [...] --status-fd 1 [...] --output - [...], i.e. fd 1 is used for status output and for the result output of gpgtar. This cannot work. To me this looks like a flawed implementation of _gpgme_io_pipe() resp. new_fd() in w32-io.c which happily returns 1 as FD on the first call.

I'll add new error codes to gpgrt

works with gpgtar (GnuPG) 2.2.42-beta102, too

I could not reproduce the problem with a self-build gpg4win 4.1.1 (e5dee8abf3045c970f4ba7a0dd7ee5daf08fe7cb). Please list the content of the folder Unterordner.

Only Sign results in the same error as Sign+Encrypt (which was the picture above)

works in 3.1.27.0-beta44

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.

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

I am pretty sure we have the same problem in 2.4 - due to different access patterns it might not exhibit itself.

Pushed to this site. Thanks for noting.

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)

I've run into a variant of this, too. If I generate they key just using (genkey (ecc (curve "Ed25519"))), it is recognized as an encryption key. One needs to use (genkey (ecc (curve "Ed25519")(flags eddsa))).

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.

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.

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.

Thanks for the report; the regression happened due to fixing T6135.

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

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:

Works for me with gpgtar (GnuPG) 2.4.1-beta21. I haven't verified this with 2.2.x.

I guess we need some gpgme support as well.

How with --status-fd passed to gpgtar we will get these progress lines:

On the mailing list I wrote down my test results for en- and decrypting files (1-10 GB) with GnuPG and Gpg4win/Kleopatra. The encryption always ran with compression. Kleopatra needed more than 11 minutes to encrypt a file that is 10 GB big. Today I tested the encryption again but this time I added

compress-level 0

to gpg.conf (I also tried to add bzip2-compress-level 0 and then only compress-algo uncompressed because Bernhard was suggesting that in the mailing list but it made no difference).