Should be fixed.

Ack from me for new 0005 and 0006.

More things to be considered:

• How to connect scdaemon
• How to invoke scdaemon

The patch for T5834 (https://dev.gnupg.org/rMad3aabdd8a64156c7e3a75d695ae1ab2c4bec841) was already applied to the build of GPGME 1.17.0 for Focal, as I did browse the list of latest GPGME bugs first before reporting this bug. Attempting to build with the latest GPGME 1.17.1 (with the included ABI patch) results in exactly the same FTBFS for i386 only, so this does appear to be a distinct issue not related to that of ABI backwards compatibility.

Does this look ok to push to master? @werner @gniibe

Please see T5834 which is fixed in 1.17.1

Fixed in 1.17.1

Note the ABI bug the Qt version of 1.17.0 which is fixed with 1.17.1 (T5872)

BTW, there are various use cases for authentication(s), it is better to focus on the part of device and crypto (USB Token and scdaemon).

Here is an experimental shell script for testing:

New versions of patches 0005 and 0006 - fixes EOF handling issues noticed with compression/decompression:

From the parent task "I think having the [...] keyselection when encrypting improved is the best way to help current users of the software who might already have received help from a collegue to import and have a list of certified certificates available."

Ready for testing

Ready for testing

I think this is not urgent as we are able to FIPS certify libgcrypt without that, but the modern protocols and algorithm use this and if we want to use libgcrypt to implement these in FIPS compliant way, we certainly need something like that.

Fixed.

Please describe your problem in more detail. Also: Which version of GpgOl and Outlook are you using, SMTP/IMAP or Exchange?

I don't think it is justified to tag this as "unbreak now" - which we use for severe bugs inhibiting the use of a deployed version.

I'm not sure. In KeyResolverCore::Private::resolve() line 668 reads

const bool pgpOnly = (!mEncrypt || !hasUnresolvedRecipients(mEncKeys, OpenPGP)) && (!mSign || mSigKeys.contains(OpenPGP));

I'd say this is supposed to check if there is an OpenPGP signing key, but I guess mSigKeys[OpenPGP] is an empty list. This may be a regression introduced by the resultion of key groups because in KeyResolverCore::Private::resolveSigningGroups() the entry mSigKeys[OpenPGP] is always set (unless we are in CMS-only mode).

Yes, unit tests still pass. So its ok with you to commit this?

What about at least accepting env variables OR tilde expansions? That will make it easier to integrate with dotfiles that intentionally use a home-dir based executable without having to pass the full path, so it could work cross platforms.

Sounds familiar, that the signing keys are not considered. I think when I worked on this, I thought that is was a bad idea to mix resolving signing and encryption keys. Do the unit tests still pass with your change?

@ikloecker
If I test the resolver code from libkleo with gpg4win-tools keyresolver binary:

pinentry-qt with new icon:

I will add a suitable icon from the Breeze style.

Closing this task since the original feature request is still in the QA queue.

Thanks, I always did it differently and never saw that because I changed the read only configs.

KConfig simply reads all sections with the same group name into the same KConfigGroup. I strongly suggest not to use`[$i] on groups. KConfig` will anyway add [$i] to all config entries (and remove it from the group) when the configuration file is saved the next time.