My test case is to import my pubkey and then run:

It's two bugs working hand in hand here.

This was fixed. The check for VS-NfD mode was crashing.

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.

I'm closing this as I've got confirmation that one crash was fixed by disabling async encryption again. And a class of general "Crash when encrypting" bugs that were related to the communication between Kleopatra and GpgOL no longer exists as Kleopatra is no longer used when encrypting from GpgOL in gpg4win 3.1.0.

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.

The second user ID in my test case was an "URL". So we now use what ever the "raw" user id data is as the Name if both name and email are empty.

I don't find an easy way to fix this.

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 )

This works now reliably in my tests.

Cancel is now handled and the key is not removed if the user canceled.

I give this high priority as I would love to have this fixed for the next release.

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.

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

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.

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.

• 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]

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

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.

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.