Installed pinentry version is:

The bug is specific to 2.2, which may select available key on card. When such a selection, checking the PK->REQ_USAGE was missed.

Shouldn't this also be applied to STABLE-BRANCH-1-4?

This problem should be gone with Gpg4win-3.1.0-beta48. While I could not reproduce it I've tried to fix it and changed the hard error to a debug log in case something is unexpected here. I believe that this is safe.

I tried to reproduce this again, using S/MIME Mails, installing gpg4win 2.x etc. It did not crash for me :-/

Hmmm, needs to be investigated.

For secmem.c this is on purpose. For the others we should fix that.

Okay. We need to add a FAILURE status so that gpgme can better report this invocation error. Due to the double fork it won't be able to see the exit status. I assume you have the same problem in Enigmail.

Thanks. Indeed this should also use the x... wrappers. It is not severe because this value is only used as a fixed constant.
Thus we won't fix it in 1.8 but should do this 1.9.

Can you please provide the version of the tool "pinentry"

Normal prio as I don't think that this is a regression.

Thanks for trying out the beta. I was about to open an issue about this as someone in the forum reported the same thing. https://wald.intevation.org/forum/message.php?msg_id=5759

@dkg thanks for the link.

Yes, I meant the document. Please note that I am also one of users of the specification (for GnuPG, and for Gnuk Token). I am not defending, but try to explain the current situation.

I think that I located the bug and fixed. I wonder why Werner put gpg20 tag.

I was referring to this document:

You describe it as 'manual'. AFAIK, it's the specification for the functionality.
I have an experience implementing the functionality, following the specification.
And my own implementation does always return 512 bytes for RSA-4096. So, I could support your opinion.

Furthermore, I changed to have an explicit command: key-attr

I can verify the problem will be solved with 3.1.0, this can be closed.

I changed the interaction so that user can specify RSA or ECC, then when it's for ECC, specifying curve.

It looks like something wrong happened in scdaemon. Could you please try with following? .gnupg/scdaemon.conf

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: