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!

On a side note, it turns out that Ubuntu Maintainers ship gpg with GnuTLS dynamically linked, so that's why I went down that road first. I compiled gpg from source for Ubuntu with ntbtls for further tests. Interesting insight is that find_cert_bysubject returns different certificates on first try on my Ubuntu Machine compared to my Windows 10 Machine:

Ok, I may see three potential problems in dirmngr->validate.c->validate_cert_chain(), but it may also be my limited familiarity with the gnupg source.

• Here we leave the certificate validation loop at the first trusted root certificate, even if it is expired as we only mark this fact for later evaluation.
• Here we seem to only ever go up the chain, never sideways as is the case in the original patch for this bug.
• And probably most impactful, here we fail the whole validation if any of the previously checked certificates is expired, so that even if we would fix the second point by checking sibling certificates, we would still get an overall failure.

What I wonder is: In a number of tests in our machines (mostly virtual machines), the TLS access to keyserver.ubuntu.com does work. I have yet to see a VM where it does not. So there must be a difference.

Not a solution yet, but some more insights.
Starting from @NoSubstitute 's log output and from @bernhard 's statement that we use ntbTLS I verified that my dirmngr.exe was indeed compiled with NTBTLS 0.2.0. I did so by running strings "C:\Program Files (x86)\GnuPG\bin\dirmngr.exe" | grep TLS which returned "This is NTBTLS 0.2.0 - Not Too Bad TLS" among other strings. I also grepped for some debug strings introduced in newer commits to verify that the NTBTLS version used is not the current HEAD of master, but at least some commit before 64f895dba734802662cbb81b64cd0b4af198ee71. I will just assume it is the actual 0.2.0 release for now.

The problem is that we replace the encrypted text and attachments with the decrypted / verified parts. This would already be a modification even without such changes like the category.

Works for me in the current Kleopatra.

Ready for testing

I implemented the following solution:

• People using screen readers can navigate from cell to cell with the arrow keys. Depending on the style there is no (or no easily perceivable) visual feedback, but that doesn't matter. A not blind person will simply perceive the Left/Right arrow keys as having no effect.
• The special behavior of QTreeView which expands or collapses items with children on Left/Right does not work anymore. Expanding/collapsing subtrees with Plus/Minus/Asterisk still works.

It was the bug of generating AEAD packet, which does:

Sorry for pushing immature fix. I located the cause, but I didn't have enough concentration for fix.

Just more background what I'm doing with these tests. I started testing with set of different sized test files (generated from urandom) to detect any bugs in my changes, which try to reduce amount of memory copies in iobuf_read/iobuf_write. Size ranges for these test-files are 0...17408, 32256...66560 and 130560...132096 bytes. These files are encrypted with different settings (public key/symmetric/cfb/ocb/different algos) and then decrypted and decrypted file compared to original.

I tested the fix. It appears to break OCB encrypting files shorter than 65515 bytes:

$ gpg --batch --symmetric --passphrase=bug --output=enc_065514.gpg --rfc4880bis --force-aead --cipher-algo AES128 --compress-algo none plain_065514
$ ls -laF *065514*
-rw-rw-r-- 1 jussi jussi   100 Feb  22 18:51 enc_065514.gpg
-rw-rw-r-- 1 jussi jussi 65514 Feb  22 18:42 plain_065514
$ sha256sum plain_065514
5711955703f4d96f510ad5a660c3ccd0d01f0b2dd2561ba6586159ad941cbcde  plain_065514
$ gpg --batch --decrypt --passphrase=bug --output=- enc_065514.gpg | sha256sum
gpg: AES.OCB encrypted session key
gpg: encrypted with 1 passphrase
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  -