Optionally, (configurable on the Directory Services page) Kleopatra now queries WKDs for all user IDs when updating an OpenPGP certificate.

So this works for me now. The user where we build gpg4win has local diversions in ~/bin so as to not affect the GnuPG builds in any way and in the dockerfile we use update-alternatives to select the posix flavor.

I confirmed that the pselect EINTR problem of Linux (at least for x86) has not yet been fixed: https://lkml.org/lkml/2018/3/21/909

The MSI Package though is a 64 bit MSI Package. For 32 Bit Windows we would need to ship a different MSI Package. (Which we actually have build support for because I thought that was neccessary even in 2020)

No, everything in Gpg4win is 32 bit, except for gpgol, gpgex and gpgme, libgpg-error and libassuan. Which are addionally installed under bin_64. But for the whole KDE stack it should easily be switchable. The KDE Windows project regularly builds them as 64bit applications. Basically we would then need to invert the logic and use the 64 bit compiler as the main compiler and the 32 bit compiler as the _ex compiler for gpgol and gpgme.

Need to do this for the docker image and this way document how to do that with update alternatives. For our build setup it made most sense to manually link it only for the Gpg4win build user and not a system wide change.

Kleopatra is a 64 bit application, right? For GnuPG we are working on 64 bit support for Windows. This is planned for 2.6. problems are how to represent sockets, file descriptors, streams and so on. Regarding the time interface, we should have everything ready in the GPGME<->GnuPG interface. In GPGME we need to check that we don't use int instead of time_t, though. When that has been done/fixed we could use a 64 bit gpgme and kleopatra along with the 32 but gnupg. Might be easier for approval reasons.

Mh, since there are no 32bit Versions of Windows sold for quite some years now maybe we should consider just going full 64bit with everything to solve this? Or is this a stupid suggestion?

It turned out that we need to fix this for use by Kleopatra on Windows.

Fixed. Removing Gentoo tag because it's not Gentoo-specific.

It may be better to open a separate issue for the issue in gpg, so that it's not overlooked/forgotten when the issue in gpgtar is fixed.

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

This looks like the same problem I encountered in Gentoo's Portage. To unlock the binary package signing key, Portage will run the equivalent of gpg --homedir ... --digest-algo ... --local-user ... --output /dev/null /dev/null. If unlocking fails (due to e.g. wrong password), /dev/null is removed: https://bugs.gentoo.org/912808

Needs to be checked for 2.4 - no backport to 2.2, though.

Needs to be checked again with stable. No backport to 2..2, though.

Won't be backported to 2.2 once we got something in 2.4.

Alternatively this is a version of it with all the information in one inline message (and clicking on Encrypted will show the recipients and clicking on key will open the key in Kleopatra)

Implemented here: https://invent.kde.org/pim/kleopatra/-/merge_requests/56

Ok. Thanks for testing. That confirms my suspicion. rOdd3ff8397aaf62e58fa9405ddc5397cb6bcfdc29 is to blame here with the setReadFlag line as the specific cause. Because it is intended to trigger a save back. The problem was that we had circumstances where other addins changed the mail and really wanted it to be saved back to the server. So we call "save" before decrypting the mail to ensure that these changes are saved and then we decrypt, put in our temporary plaintext and ensure that the plaintext never is saved.

I testet it with 4.10 and GggOL 2.5.6. The file isn't changed if I open it. So it seems the change happend in 4.2.0.

Do you know if this is something new that started to happen with 4.2.0 for the first time or did it happen with 4.1.0, too?

My question would be, should we try to improve KConfig in some way which makes it easy for us to do this? I think we should, if this is a common problem for many applications. Maybe a task for sune?

I'm not sure, but you may also want to sync the state config (which stores mostly window geometries). In fact, we might want to use the state config for more settings that change often, e.g. the different last used directories.

We decided to keep the current behavior as default (privacy by default), but to add an option to enable WKD lookups for all user IDs.

I found a troff reference: https://www.quut.com/berlin/ms/troff.html

Ideally, we should change the source document to use @minus{} for a minus sign, and keep - only when it means a hyphen. But we cannot do that blindly; We need to handle it with care, in a way of case by case (Texinfo manual suggests no use of @minus{} with @code or @example, but it is needed for groff man pages in many cases).... We would need to consider each occurrence of - in our document. That's too much (if it were me to fix).

Yes, since we also don't have a ton of "temporary" changes (except for window geometries) such a behavior would make the most sense.
Does it even make sense for us in these places to use KSharedConfig?

In T5903#174528, @ikloecker wrote:

OpenPGP keys are now also updated via WKD, but only for user IDs which were originally retrieved via WKD (i.e. which have origin WKD).

I'll swap us over to out of source build for this as well. I've been doing it gradually for the gpg suite. Thanks.

The following patch fixes this (for me):

diff --git a/lang/qt/tests/Makefile.am b/lang/qt/tests/Makefile.am
index 32ad6466..aedd3264 100644
--- a/lang/qt/tests/Makefile.am
+++ b/lang/qt/tests/Makefile.am
@@ -51,10 +51,10 @@ LDADD = ../../cpp/src/libgpgmepp.la ../src/libqgpgme.la \
         ../../../src/libgpgme.la @GPGME_QT5_LIBS@ @GPG_ERROR_LIBS@ \
         @GPGME_QT5TEST_LIBS@ @LDADD_FOR_TESTS_KLUDGE@ -lstdc++

This happens because you build in the source directory and therefore the wrong debug.h is found. While this should work in general we strongly suggest to use a separate build directory.

The changes have been backported to VSD. Note that they require today's changes in gpgme (just after the release of gpgme 1.22.0).

OpenPGP keys are now also updated via WKD, but only for user IDs which were originally retrieved via WKD (i.e. which have origin WKD).