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.

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

I realized that KDF support may be incompatible to Gnuk's feature of "admin-less" mode.
I'm going to implement compatible KDF support to Gnuk; That is, KDF data which only has a single salt.
In this case, all KDF calculation (user, reset-code, and admin) is done with the single salt.
With single salt, admin-less mode can work with no problem.

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.

fixed with rev. 4fbbd134b865b1203b1914eb1623fa65aab8cb75