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  -

@NoSubstitute It is okay for me to keep this issue, if most people prefer it this way, was just asking.

@bernard - well, that's the kicker, isn't it.

Ah, just seeing that this issue is resolved. Shall we open a new one to be well structured?
(If we reopen this one, there is a lot of old information in here that does not apply anymore before the fixes that went into dirmngr/gnupg).

Does gpg4win ship a TLS library with gpg or does it use a system default?

@ikloecker thanks for the hint (At first it looked like a different defect.)

Alright, in the hope it helps to pin this down, trying to sum up what I tried during and after my conversation with @bernhard so far:

• Windows 10 keeps both the old and new root CA in the store and manual edits to the root certificate store are undone by the OS sooner or later
• ignoring the intermediate certificate with dirmngr --ignore-cert 48504E974C0DAC5B5CD476C8202274B24C8C7172 fixes the problem as a workaround, but is not a satisfying solution
• I cloned the repository and took a look at the original patch; while it seems that we only check validity of certificates without considering the expiration date, the patch does fix the original bug which I confirmed by compiling gpg from source at the commit containing the patch and another version at the commit prior to the patch. That is, the patch successfully fixes this on my Ubuntu machine. On my Windows 10 machine the bug persists no matter if using a self-compiled version from those commits or the official versions from gpg4win.
• During exploring the source code and finding out how to compile and test from source I found out that I can reproduce the bug on Ubuntu if I compile gpg with the patch applied, but with a GnuTLS version that does not have their patch for this issue. Since this is the case with the default GnuTLS dev sources in Ubuntu 20.04., I had to get GnuTLS library from the project itself in order to successfully compile gpg for Ubuntu. For Windows the problem persists, however. I did not find GnuTLS or any other TLS library in the application directory of the GPG install on Windows nor in the installer itself. So I'm wondering if the remaining issue on Windows is actually with the used TLS library there. Does gpg4win ship a TLS library with gpg or does it use a system default?
• The fixed version of GnuTLS is 3.6.14 for the project itself, there are backports of this patch for Ubuntu Xenial and Bionic, unfortunately not for Focal yet.

Sorry.

This has already been fixed: T5711: Kleopatra: Keyserver config does not fallback to default.

In T5848#155277, @bernhard wrote:

@hakan-int :

As soon as I change the value and check the "dirmngr"file, it is overwriten with the "keyserver hkps://" value again.

(I hope only if you completely delete it, as it should keep any other value and write it to file.)

As soon as I change the value and check the "dirmngr"file, it is overwriten with the "keyserver hkps://" value again.

Hello.
@bernard has been so kind to try and help me with this exact issue over in the gpg4win forum, and it seems I'm not the only one who still has problems with the "broken" LE certificate chain and hkps://keyserver.ubuntu.com.

First observations regarding screen readers and the certificate table:

• The comment in the report that only the name (in the first column) is read may be an issue of the screen reader.
• Orca reads all table cells (because of the (default) settings "readFullRowInGUITable"). There is also a keyboard shortcut to "toggle the reading of tables, either by single cell or whole row". I expect that other screen readers have similar settings and toggle functionality.
• I don't think navigation by cell makes sense, because this is a read-only table, i.e. interaction with individual cells isn't possible.

@bernhard when I close Kleopatra and stop the its task by the task manager, then the value remains. But as long as I do not change the default value to an other value in "Settings" -> "Configure Kleopatra". As soon as I change the value and check the "dirmngr"file, it is overwriten with the "keyserver hkps://" value again. I think, this is not the expected default value, is it?

@werner the main issue here, that Hakan has found a usability problem:

Actually all changes Kleopatra does go through gpgconf. Thus is is normal that gpgconf overwrites things.

When I overwrite the default value "hkps://keyserver.ubuntu.com" with another value in "Settings" -> "Configure Kleopatra" once and click "Apply or OK" and delete this new value again, then Kleopatra does not insert the default value to the necessary place again.

Feel free to ask me by PM if you run into problems (wk at gnupg.org). Two of my colleagues are Vim users and thus have an interest in a well working plugin :-). Thanks.

Thanks! This plugin has been around for a long time, and this is one aspect I inherited from the original code. I'll look into reworking it to use the status output.

Try with hkp:// - I assume that you are missing the new Lets Encrypt CA certificates

Why are you using the log output for scripting? This is not its intended use. You need to use --status-fd. Log output is purely for human consumption it not a stable API. BTW, --fixed-list-mode has gone ages ago but it does not harm.

The user who made the first report about this issue, it could help: Forum Wald

We (@hakan-int and myself) saw the problematic behaviour in one setting. It was a VM where Gpg4win had been installed, deinstalled and reinstalled again. We still try to find out how to reliably recreate the situation and what is the difference between a working and a non-working case.

I suspected that it would be listed by gpg --dump-options, but I didn't think about autocompletion cleverly using it. I apologize.

How does the user know about the feature in the first place, other than reading the source code or searching the executable for "hidden" command-line flags?

Generating a new OpenPGP certificate with default settings should now be possible:

• with keyboard only (tab order should be okay now)
• with high contrast color scheme and/or inverted color scheme (tested with Breeze Dark)

There is another hacker working on finishing it. I only provided the framework.

@werner will have to answer why he added the unfinished code. My guess is that he wanted to prevent it from being lost on his computer. I would probably have deactivated the code as long as it's unfinished.

For the next release T5842 (so with a higher priority) I have picked

Yes. Sorry about that. We had multiple issues where attachments were hidden and not shown as attachments because they had a content-id but that content-id was not referenced in a way that outlook shows.