Nope. The corner widget is the suggested way in outlook and users are used to it / accept it.

According to this thread on stackoverflow: https://stackoverflow.com/questions/32712399/c-sharp-vsto-outlook-itemsend-event-execution-order

Long enough time to object to just killing stuff. We are killers now. -> Resolved.

I looked into it a bit. As bulk import is highly inefficient copying the keyring lots and lots of times the migration of a keyring with 1000keys takes around 6 Minutes.

Works now with and without attachment and with encryption / without encryption (formerly without encryption it would add the original crypo message as attachments).

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.