I got beta feedback which after analysis showed that parts of the encrypt changes in 3.1 that would have addressed this lead to crashes. So we had to disable it for now and block Outlook again as temporary blocking is better then "random" crashing :-((

Reproduced again with a brand new Yubikey 4 Nano on another Arch Linux machine with a newly created test keychain:

I experienced this issue today while cleaning up my keychain. I recently switched from pgp to tofu+pgp trustmodel and this caused me the above error when doing:

fyi, I pointed folks at https://github.com/keybase/keybase-issues/issues/1712#issuecomment-372158682 to this issue

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.

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

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.

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.

(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.

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

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.

Thanks a lot for your testing. So, apparently, the PC/SC behavior is different between GNU/Linux and Windows.
Thus, I pushed another change: rG1e27c0e04cd3: scd: More fix with PC/SC for Windows.. Please test this. (Both of previous version and this version work well on GNU/Linux for operations not including suspend/resume with Yubikey and Gnuk Token, while my Yubikey with PC/SC doesn't work well for suspend/resume.)

Thanks, this version of scdaemon executes.

I think the problem is more that NSIS uses this arcane build system which makes it hard to cross compile.
NSIS 3.0 is also not in experimental.

About Debian: Stable releases are only updated for bug fixes and not for new features. This is an important for almost all production systems. Rolling release distros do not provide a platform which can be used to replicate use cases or problems.

there is only NSIS 2.51 in debian

Cool! Thanks for testing :-)

Thanks for the help,

I can't reproduce this. I sent myself a Mail with capitalized "Andre.Heinecke@intevation.de" while my key only has an identity for "andre.heinecke@intevation.de" and it worked as expected:

Mh, that is strange and indeed a bug if that is so. GpgOL should do some simple normalisation which should prevent exactly such a problem. I'll look into it.

Question has been answered. Closing this.

Thanks for the hints.
The problem for us is that we want to rely on Debian Stable for building Gpg4win and there is only NSIS 2.51 in debian :-/ Maybe we make an exception and package NSIS 3 ourself for debian.

With 3.1 ( https://www.gpg4win.org/version3.1.html ) the problem should be gone. We still have to block outlook when the inline editor is used but that left no artifacts in the past. And if a Mail Window is opened we do not block outlook anymore. We only disable it to show a modal dialog.

At some point we really need to look at better error handling so that such an error would be more visible in the UI.

Thanks for your help / report.

With Gpg4win 3.1.0 ( https://files.gpg4win.org/Beta/gpg4win-3.1.0-beta-current.exe ) GpgOL no longer uses Kleopatra for signing. So this problem can no longer exist.

I'm lowering the priority to Normal. I've done a lot of GpgOL work and Testing for the upcoming 3.1.0 release and have not seen this problem.

Got confirmation In Bugs.kde.org that this is fixed https://bugs.kde.org/show_bug.cgi?id=389792 as my tests also showed this -> resolved.

Sorry, my build was not good even if it's for x86_64 (I used development version of libassuan, etc.).

Probably you are right but I don't know Windows internals that much.

I installed 3.1.0-beta and tested all use cases, everything is working properly now.

Should work with the current beta: https://files.gpg4win.org/Beta/gpg4win-3.1.0-beta-current.exe Although the window mangement is still a bit "iffy" but we at least switch back the focus.

Yes sorry, I decided against a release specially for that is it is not super critical, no data loss.

A beta of the next version where this is fixed is available now: https://files.gpg4win.org/Beta/gpg4win-3.1.0-beta-current.exe

I've uploaded a beta for the upcoming 3.1.0 Version: https://files.gpg4win.org/Beta/gpg4win-3.1.0-beta-current.exe

I wonder if this also works similar in a multi user system:

Fixed. But you need to wait at least 4 seconds even with a 2 seconds ttl. Will go in 2.2.6 in about 3 weeks. Thanks for reporting.

Great.
I'll wait for v3.1.0 then.

Well, if you have access to the user's memory you are lost anyway. Should be fixed, though.

From the log I can see that GpgOL picks up the wrong "Sender" address. It thinks that you sent the mail yourself and then the mail address <> signature does not match. So it is not flagged as Trusted.

Thanks for the report. The broken sentence came from an unterminated hyperlink. I fixed the spelling and the link.

@gniibe it seems the patched scdaemon.exe is 64 bit executable and it requires libassuan6-0.dll. However I got installed 32 bit version of gpg that only has incompatible libassuan-0.dll. I scanned whole computer for the missing lib, skimmed your ftp for 64 bit binaries and looked into gpg4win installer to find it, but no luck. There is also libassuan github repo, but I would like to avoid building the dll myself; there would probably be more than one dll to build anyway.

If possible, please try with this (patched version of scdaemon):

I realized that suspend/resume is not supported yet on GNU/Linux: https://anonscm.debian.org/cgit/pcsclite/PCSC.git/tree/TODO#n7
So, I can't test myself.
Here is an attempt to improve:

It looks like SCardGetStatusChange doesn't return failure after wake up.
Here, what we need is catching the event of wake up, which requires reset of the card.
I think that we can check by the dwEventState field.
I'll try on GNU/Linux environment, then ask you to try.

@werner there had to be some mix up, as the log snippet is not mine.

This seems to be the relevant part of the log:

2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card inactive/removed
2017-11-18 07:45:15 scdaemon[8918] ccid open error: skip
2017-11-18 07:45:15 scdaemon[8918] pcsc_establish_context failed: no service (0x8010001d)
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: interrupt callback 0
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card removed

This would be a good solution.

This has also the advantage that we could list the possible curves and let the user select them.

So should we revert this patch and replace it by an explicit command to switch the card to ECC?

It looks like you're having the same issue that I reported: T3761.

Hey, @uwestoehr. It looks like you're having the same issue that I reported: T3761.

Ok, thanks!

Sadly this is a known problem, the workaround is to unselect the mail and then move / modify it through the right click menu.