Oh ok!
Thanks

This change is wrong. The correct fix is rM31423945d214: qt: Fix filename of cmake config files for w32.

Applied with rMd42323f90213: qt: Add #include <QStringList> needed for building against qt6

In D558#5636, @ikloecker wrote:

You have not yet sent a signed DCO to gnupg-devel@gnupg.org (or it's stuck in the moderation queue). Moreover, you do not seem to have signed off your commit.

I think it's best if you send your patches to gnupg-devel@gnupg.org instead of using dev.gnupg.org. Phabricator makes it too difficult to apply your commits.

Sorry. Just saw that you have signed off your commit.

You have not yet sent a signed DCO to gnupg-devel@gnupg.org (or it's stuck in the moderation queue). Moreover, you do not seem to have signed off your commit.

@werner For what it's worth, I would like to apologize for my rudeness and disrespect. I had a quite convoluted notion of what the development process entailed. In particular, I was ignorant of the different and opposing responsibilities and the separation of concerns involved in the development process. In retrospect, there were at least a dozen different ways in which this could/should have been handled and all of them are downstream.

Ping ?

Applied and pushed.

The last patch is related to FIPS, so, I add the FIPS tag.

Please find the requested log attached.
I don't know, where to look for such a file (candidate).

I'll prioritize this as Wishlist because the options in the "GnuPG System" tab come directly from gpgconf and they are meant to be used by experts (who read man gpg, etc.) and maybe for users who are instructed by an IT administrator to enter some value for some option (so that those users do not need to edit some configuration file).

@gniibe Sorry for bothering but I couldnt find any answers to this online, is there any ETA for the v5 specification being released?

In T6050#159616, @gniibe wrote:

Thank you for your report.

V5 key (which is used by Ed448) is not implemented yet. See the function convert_from_openpgp_main in gnupg/agent/cvt-openpgp.c, where it parses the version of the key; Only version 3 and version 4 are implemented.

Please note that the implementation is buggy and not for use, because the OpenPGP v5 spec has been changed since then.

Kleopatra uses SCD READCERT for reading certificates from the PIV app. This is used to import the certificates stored by the PIV app. I'm not sure whether this is really needed. Maybe we could/should use "learn card" for this instead.

Yes, only settings from the "GnuPG System" tab are involved

We could change how device keys are listed. Currently, Scute does KEYINFO --list, then asking gpgsm for each certificate.

Thank you for your report.

The change requires "KEYINFO --list" command. This is not available through remote access of gpg-agent (extra socket).

The first ideas sounds best to me. Patches please to the mailing list.

I think it's worth noting that this is not restricted to encrypted e-mails but signed-only e-mails also.

Is this only about options shown on the "GnuPG System" tab?

The tool tip pop-ups are now read out by orca (if reading out tool tips is enabled; it's disabled by default).

Thanks for the log and the analysis so far. In the log it is visible that the problem is that gpgol cannot create a temporary file to store the mails contents. Due to this it fails later as it has no data to encrypt. The storage as a temporary file was added in 3.1.16 to allow more embedded outlook objects since we now ask Outlook to first serialize the file. I wonder why this only occurs to very few people. Obviously it works for most people, including me.

Applied the changes to master.

Thank's Diedrichs for this hint.
Here it works again using Gpg4win V.3.1.15.

Key length requirements for KDFs are specified in SP 800-131Ar2 (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf), which is linked from SP 800-140Dr1 (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Dr1.pdf) in section "6.2.1 Transitions".

FIPS 140-3 (https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-standards) points to SP 800-140Dr1 (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Dr1.pdf) to list acceptable "Security Parameter Generation and Establishment Methods". From this document, RFC 5869 (i.e., HKDF with the counter at the end) can be reached via two paths: