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

In T5639#155478, @werner wrote:

echo BYE | dirmngr -vv --server 2>certs.log

Lists all certificates

I tend to agree

@TheParanoidProgrammer this looks like a very good and thorough analysis, thanks again!

I used "1<<30" by example of existing code in g10/free-packet.c, which is another place where iobuf_read is reading to NULL.

Patches look good for me.
Please go ahead.

Ok, I managed to find 48504E974C0DAC5B5CD476C8202274B24C8C7172 via Powershell. It was in the CA store of my non-privileged user and since I always checked the certificate store as administrator it did not show up there. After removal of this intermediate certificate I am able to use hkps://keyserver.ubuntu.com.

Ok, so order of loading is not a problem since the cache does not store them by insertion order, but instead indexes them by the first byte of their fingerprint.
So, I think the problem here is that the expired intermediate certificate (48504E974C0DAC5B5CD476C8202274B24C8C7172) is somehow loaded in Windows and since its fingerprint's first byte is less than the server-supplied intermediate (A053375BFE84E8B748782C7CEE15827A6AF5A405) Windows chooses this one. I can see that the expired intermediate certificate is indeed loaded on Windows if I increase verbosity of dirmngr logs. However, I am still unsure where this certificate lives. The log says it comes from the "CA" store, but searching for it visually or by fingerprint search in Windows Certificates Snap-In (MMC) does not let me find it.
I will keep looking, but if you want to reproduce in your VMs, I suppose adding the expired intermediate certificate and the expired root certificate to the system store should make this reproducible.

(note: -O2 is added only for compiling powerpc vector implementation files)

I added check to configure.ac for missing -O flag and tests with -O2. If adding -O2 does not help, then powerpc vector implementations wont be build at all.

Does the patches look ok to push to master? @werner @gniibe

Thanks. All my tests work now.

Removing the list seems reasonable to me, we can tell users in support that they should go to settings- > Smartcard to select the reader used.

There is now a dedicated configuration module for smart card related settings. Currently, it's rather empty, but maybe there are more smart card settings you want to see there.

Cool. I did some quick tests with 2.2 on my pretty old X220 and it really makes sense to apply the patch there as well.:

aheinecke: Good idea

Do you mean revoking the entire key or a user-id, or a subkey? Having a way to revoke a user-id is probably the most interesting use-case. BTW, there is no "revoke a self-signature" - this is actually a revocation of the user-id or subkey.

Related to this is that I was looking for a way to revoke my own key and I thought that revoking the selfsig might work. So maybe it makes sense not to fix this by forbidding this operation but instead by allowing it with the same key.

I have an uncommitted SmartCardConfigurationPage. I guess, I'll simply commit this and remove the "List smartcard readers" option.

@TheParanoidProgrammer thanks for investigating further. It is highly appreciated!