Since I don't have macOS environment and Yubikey 4 (I only have old Yubikey), I hesitated to claim this ticket. But it is me who should take this one.

Mr. Heinecke, to make sure, please note that despite the thread title these crashes happened with 3.1.0. beta 38. It would be sad if you do all of the tests and checks with 3.0.3

Apologies for not replying to your mail directly. I've marked it in my INBOX to do the test with 3.0.3 first but have not gotten around to it.

Funny thing, it worked for some time, now it's reproducably crashing again. This might be the better log file.

So, this is tested with 3.1.0 beta 38, reproducable crash

I answered by mail in this fashion:

The severe delay caused by check-trustdb continues to cause problems elsewhere in the ecosystem. It would be great to try to address this so that GnuPG was more responsive for routine tasks like importing a single key.

Was reported to me again in the context of paperkey export / print secret key in Kleopatra.

Got it. This was a bug that was around for ages but only started to occur in the verificationresult when we started in 3.0 to show the KeyID / Options for the unknown certificates.

rO4c5eed308829 fixes this.

Again, thanks for your time testing it again.

1. it is reproducible
2. Kleopatra crashes at the end of the verification of a signature
3. it is a openPGP signature
4. please see first picture
5. I have only openPGP certificates in Kleopatra

We don't support v3 keys at all.

Thanks for trying out the beta and your report.

Fix was released with GPGME 1.10.0

It's two bugs working hand in hand here.

Thanks a lot!
The log shows pretty much whats going wrong. I've opened T3863 for this to have a clear issue for the problem.

I've upgraded to 3.1.0 beta 38 and sent an encrypted, non-signed e-mail to myself.
The received e-mail was shown unencrypted in inbox. See log-file below.

Thanks for your report. Sadly I cannot reproduce this, I went back in my archives and even mails from 2015 / touched by Gpg4win 2.x work without a problem.

Thanks. After seeing this report I ran a spellchecker on the translation and found some more typos ;-) Will be fixed in the next version.

This should no longer happen with Gpg4win-3.1.0 as GpgOL now uses gnupg's --locate-key mechanism to find a matching key.

In T3769#111899, @hs wrote:

Behavior is the same as 3.0.3 /3.1.0beta32.
It reads encrypted e-mails if Titus plugin is disables (GpgOL as the only plugin).

Behavior is the same as 3.0.3 /3.1.0beta32.
It reads encrypted e-mails if Titus plugin is disables (GpgOL as the only plugin).
Strange: Both beta32 and beta38 show the recipients box after pressing the send button, but
the messages are sent unencrypted. After downgrading to 3.0.3 messages are sent encryted,
again.

Could you please test again with the beta38 (or later) from https://www.gpg4win.org/version3.1-de.html It contains the change now.

Thanks for your report. This has been fixed for the next version ( https://bugs.kde.org/show_bug.cgi?id=391222 )

Thanks for testing and the confirmation / praise ;-)

Hi Andre,
AWESOME! Thanks a lot. It works and it’s also faster. GREAT!!!
Jacques

From: aheinecke (Andre Heinecke) [mailto:noreply@dev.gnupg.org]
Sent: March 21, 2018 2:41 AM
To: Jacques Latour <Jacques.Latour@cira.ca>
Subject: [Task] [Changed Status] T3847: Pinentry-qt pop up not appearing when I send a signed/encrypted email

aheinecke changed the task status from "Open" to "Testing".
aheinecke triaged this task as "Normal" priority.
aheinecke added projects: gpgol, gpg4win.
aheinecke added a comment.

Hi,

I'm not 100% certain but I think that it is likely that your problem is fixed with the upcoming 3.1 version. We have reworked how GpgOL encrypts there a bit ( T3509https://dev.gnupg.org/T3509 )

Could you please try out the beta of the upcoming version https://www.gpg4win.org/version3.1.html and confirm that the problem is either still there or gone?

Thanks!

TASK DETAIL
https://dev.gnupg.org/T3847

EMAIL PREFERENCES
https://dev.gnupg.org/settings/panel/emailpreferences/

To: aheinecke

Cc: aheinecke, latour_jacques, Mak, gp_ast

This is an automated email from the GnuPG development hub. If you have registered in the past at https://bugs.gnupg.org/ your account was migrated automatically. You can visit https://dev.gnupg.org/ to set a new password and update your email preferences.

I just tested changing passphrases and indeed this is very ugly. Especially as this opens up a wide range of error states where you have different passphrases for different subkeys etc.

I'm not 100% certain but I think that it is likely that your problem is fixed with the upcoming 3.1 version. We have reworked how GpgOL encrypts there a bit ( T3509 )

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.