The use case that @Valodim and @dkg are thinking of probably is using a setup-code that humans use to transfer from one device do another to decrypt a symmetrically encrypted setup-package, this issue is linked from:

https://autocrypt.org/level1.html#setup-message-import

Ok the problem really seems to be how parameters are parsed.

Please use one of the channels under https://www.gpg4win.org/community.html for general usage questions.

This is fixed by no longer using kleopatra for this ( T3509 )

All right. It might not be that bad. I messed up with between --armor and -armor but they lead to different results:

Hallo Werner,

Even more weirdness here. So on my test .gnupg directory I just removed the public key of the unwanted recipient.

I went ahead and modified my ~/.gnupg/gpg.conf to use the valid RSA2048 key I want to use for the recipient:

I need to look closer at some details. However it seems that because your default-key has no valid encryption key, --default-recipient-self tells gpg to encrypt to the first usable key in the keyring. This is clearly a bug.

So I implemented a way to forward mails with attachments. TODO here:

Here is more details. One thing to notice is that the default key mentioned in my config files no longer has valid subkeys since they have all recently expired. I'm in a process of updating them but since I'm only encrypting (and not signing) for a different key I thouhgt it wouldn't be an issue.
I could just delete the offending pub key or clean up my pub keyring but I think it would be good to understand that issue in case there is a weird parsing error.

I've contacted Yubico to review this ticket.

Hi, that works as advertised. If this is the best solution yubikey permits us I am ok with it.

Please add -v to all gpg invocations to increase the verbosity. I would also like to see your gpg.conf.

Attached Patch:

(BTW, --create is not an option - you meant --encrypt)

That is not easy to fix in a shell script. I would prefer to get rid of gpg-zip or make it a simple wrapper around gpgtar like

I put an entry: https://wiki.gnupg.org/SmartCard#Known_problem_of_Yubikey

After resume, because resume is not detected, some user interaction is required to cause an error.
gpg --card-status (which will only show partial information) is enough. Or, ssh failure. After failure, scdaemon reconnects the token.
Then, you can use it again without plug-off/plug-in.

Thanks a lot for pointers and suggestion.
Well, the problem of Yubikey itself cannot be solved by others, we can put some workaround for the error recovery.
So, this is another try of mine to improve error recovery.

Hi @aheinecke
I Can confirm, its working for me fine now.
thanks
Martin

• There was same problem in yubico-piv-tool and it was solved by detecting error state (0x80100068) and reconnecting to the smart card if necessary [1]
• There is also a thread in OpenSC discussing this issue [2] and relevant PRs [3]
• I also found a project that claims to fix SCARD_W_RESET_CARD by disabling exclusive access to the card before asking for PIN (and then they enable exclusive access again) [4]

New cards will come with a fix. I am not sure whether a production run has yet been done, though.

From one user I have received a debug log of the current beta where it apparently crashes in the dtor of the mail object after send.

*no other tool using

On other tool using, we are using encryption command in .bat file and this file is being executed from .net code

I'll look into it, but I can't make a promise that this is fixable, Outlook appears to take the wrong data then for printing :-/

There is no automatic deletion in gpg4win / GnuPG. Is there maybe any script that is interfering or is somehow your %APPDATA% directory removed after 5 days?

Part of the problem is Yubikey side, I suppose. (Because my implementation of Gnuk Token has no problem for suspend/resume if it's in-use.)

Again, thanks a lot for your testing. The log said: The code I added cannot detect the event of suspend/resume.
It seems that there is no way to recover from suspend/resume for Yubikey.

Hello again,

Yeah, this is better, we got apdu_get_status => sw=0x0 status=7 and I can auth with this version as usual. After sleep-wake cycle it would however fail with pcsc_transmit failed: reset card (0x80100068). Logs attached.

IMO the parent key should not be hard coded to 81000001 (Microsoft preferred RSA incarnation of the storage seed), as this prevents the use other configurations (although deployed TPM2's and fTPM2's all seem to carry this storage seed).