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.

It may be simpler if we can enhance scdaemon to have an option for PKAUTH, say, --challenge-response, so that it generates a challenge and verify signature internally.

Possibly, it could be done with pam_exec http://linux-pam.org/Linux-PAM-html/sag-pam_exec.html
developing a simple executable (or even small shell script).

Great. No problem for me.

No problem. Both patches look good.

do you mean "dirmngr on Windows choses this one"? As in my mental model, dirmngr only loads all certifices from the windows stores on startup, but not during operations when requests come in (I maybe wrong though, I did not inspect the source code on this).

But in Windows 10 I get nothing in the certs.log file.

In TLS 1.2, it refers RFC5116. In RFC5116, it says:

My reading was wrong; Indeed we use memcpy from out_ctr. But it increments in network byte order.
So, for AES-GCM, it works well.

Does these patches look ok? @gniibe @werner