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.

For our internal tests this boils down to testing:

• with keyboard only
• for people using a screenreader
• with 400 % magnification
• with high contrast color scheme
• with inverted color scheme

My direct problem is to silence warnings for newer GCC.

What is the problem here? Some compiler warning about fully legal code?

Ah! Sorry! Is there any reason the command-line flag made it to a release? How should the user know that the feature does not work, other than reading the bugtracker and source code?

You are trying to use unfinished code. See https://dev.gnupg.org/rGafe5fcda52e88438c7a7278117b2e03f510a9c1c. It's not really surprising that unfinished code doesn't work.

I tested encrypt two txt files with filename 1 and 2.txt and insert text: test 1 and test 2. Tararchive has been created successfull. Than i tested this Two txt files with a long name. See attached txt files, i send it already to you. Now by the first test Archive.tar.gpg.yqoirl with 0 Bytes was created.
Second test, the other archive.tar.gpg with 0 Bytes was created and gpgex hang.

It seems you have replaced the scdaemon module from GnuPG by a 3rd party module (which exhibits a version number 0.10.0) - this is not supported and you will of course run into errors.

What you uploaded are files with a length of zero bytes. That is not valid data. The hang should not happen of course.

In T5837#155062, @werner wrote:

Setting the management key has been implemented only for Yubikeys. So for Gemalto this won't work.

Setting the management key has been implemented only for Yubikeys. So for Gemalto this won't work.

I have tested it. When I try it with public keyserver it has of course problematic results when vandalized keys like werners are hit but its great that even if I abort at that point I nicely see the results of the other imports.

It should not really hurt to query the scdaemon again after an import. We can do this in the background and users wont have to notice it in the general case where imports from others happen.

In https://wald.intevation.org/forum/forum.php?thread_id=2395&forum_id=21&group_id=11 "Kim Nilsson on 2022-02-15 16:48" reports that

I wonder why a platform has no cmp but comes with printf, which is a modern POSIX extension to Unix.

Thank you for your suggestion.

I simplified the script not to use cmp: rC3c8b6c4a9cad: fips: Fix gen-note-integrity.sh script not to use cmp utility.
And I clarified the semantics of the integrity check.

Ah, right, I can get that added to the containers tomorrow.

I located the cause:

../../src/gen-note-integrity.sh: line 78: cmp: command not found

Yeah, please do issue a new release as soon as possible if you can, as otherwise downstream we're in an awkward position where we have to rebuild everything without a SONAME bump, then do it again once the release is out.

@werner Please release a gpgme-1.17.1 with

diff --git a/configure.ac b/configure.ac
index f6d4b50e..57e6ea2e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -64,8 +64,8 @@ LIBGPGMEPP_LT_CURRENT=20
 LIBGPGMEPP_LT_AGE=14
 LIBGPGMEPP_LT_REVISION=0

That only seems to work in some configurations: https://gitlab.com/redhat-crypto/libgcrypt/libgcrypt-mirror/-/pipelines/472626834

The actual problem isn't the removed internal symbols, but

'method virtual QGpgME::KeyForMailboxJob* QGpgME::Protocol::keyForMailboxJob() const' has some sub-type changes:
  the vtable offset of method virtual QGpgME::KeyForMailboxJob* QGpgME::Protocol::keyForMailboxJob() const changed from 28 to 31
    note that this is an ABI incompatible change to the vtable of class QGpgME::Protocol

KMail calls keyForMailboxJob(), but because of the changed index in the vtable it called addUserIDJob() which ultimately caused the crash.