Thanks for the report and the spelling fixes :-)

Will be in 2.2.6.

Thanks for the pointer. But as long as the Windows ssh server is that instable I see no urgent need to add this to GnuPG.

Oh, you used a single dash and not a double dash in --armor. That is obviously the problem. As per Unix history all option characters may be combined unless they take an option arg; in that case the arg for the option may go directly after the option letter. We can't change that because lots of people and scripts use -rRECIPIENT.

Thanks for the report.

Fixed for forthcoming 2.2.6. Because of T3781: ECC encryption key on-card generation broken.
rG820380335a20: g10: Add "key-attr" command for --card-edit.

I see. Got it.

To be released with 2.26 next week

Right with (2) (1) will not occur if the key has been created with GnuPG. However, we have caches in the code path and further rogue software may create creates, interesting keys (tm). Thus I consider it better to explicitly request keys with cert flag set.

The patch has two parts; (1) detecting signature by incapable key and (2) limiting key with relevant capability.
I think that (1) is enough. I wonder with (2), (1) would not occur.

Forget my former comment. We only need to check subkeys becuase the primary key can always certify.
Here is a new revision of the patch:

I have another patch proposal to check the key usage. However, there is a catch-22. We get the usage flags from the key signatures and thus we can only check them after we checked the key signature.

The gpg20 tag was a typo.

Sorry, the patch above is completely wrong, since pk->pubkey_usage is not the right key to check.

If someone claims this is a kind of vulnerability, I think that what we need to fix is signature checking side:

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"

Pushed different version (with teardown-fn).

In T3864#112250, @aheinecke wrote:

• Resetting the GnuPG Profile back to default in Kleopatra does not work.

I doubt that I will be able to fix this. The problem is that for Outlook we build the signed mail structure, which is a multipart MIME message. If you receive such a mail with a non crypto client you see the plain text and a pgp-signature attachment. That is why Outlook shows it as "attachment".

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

• Aborting the keyresolver results in error code 5 in GpgOL
• Resetting the GnuPG Profile back to default in Kleopatra does not work.
• Add uid in Kleopatra results in General Error.