The way how you install it can have nothing to do with that, it must be a different issue, but it sounds to me like you are messing with privileges a bit too much. Did you ever receive the warning of Kleopatra that you are running it as Administrator and that will mess up the rights in your GnuPG folder? Be honest. :)

You mean if you right click on a file and select sign & encrypt or if you choose the action from Kleopatra?

For another user this change caused endless syncs. Since I do not yet see a way to fix this without risking again that the plaintext leaks to the server under some circumstances, because the problem is that I still do not know how to reproduce these circumstances, my plan is to at least add an option in the debug tab of Kleopatra to disable this "save back" feature.

This looks to me like the typical thing where you also do not get the "Diagnostics" button viewed. Because log-file is set in the various .conf files and the stderr does not get back to GPGME / Kleopatra so we have nothing to show there because the actual error ended up in a log file.

Btw. if the keyserver is set to "none" or whatever the new value is worded we should remove all the publishing options from the UI. But that is a different issue, I just noticed this while talking about this ticket.

If I revoke a certificcation I am asked to "publish revocation".
When certifying there is the checkbox to publish.

Tested with current version. Works.

I misunderstood the issue. When I created the GnuPG VS-Desktop package I did not wrote a qt.conf file which thanks to our patch https://dev.gnupg.org/source/gpg4win/browse/master/patches/qtbase/0001-Gpg4win-qstandardpaths-patch.patch caused all config files for Gpg4win to be placed under %APPDATA%\kleopatra. This was by accident since it uses NSIS FileWrite and FileWrite is not supported in our NSIS to MSI packaging.

Well 5.4.2 o.O and we on Tumbleweed are at 13.x gcc

So I think that the problem here is that ArchLinux either does not build Qt6 with -fPIC or it does and others don't and that our check for wether or not to add -fPIC is not really working as it should. When compiling executables we should also add -fPIE instead of -fPIC.

So by we already have code to handle this problem, we had code for "No body but multipart/mixed" and your message was "empty body but multipart mixed" so I just needed to also check for an empty body and the code worked.

Ah damn, now that I closed this as a duplicate I found that we already have code to handle this problem.

I found this related to that: https://sourceware.org/bugzilla/show_bug.cgi?id=28875

I have analyzed this. In the ribbon we get a mailitem OOM object as reference, but that can be a different pointer then the one we used for decryption / verification. Our trick for this was to assign mailitems a custom uuid property and then look for that from the riboon pointer so that we can update accoringly with our internal Mail object representation.

At least GnuPG only shows the most recent key signature tag. So if we leave it out when adding another signature then we remove this.

Yes remove this / leave this empty. I think the idea was that if you certify lots of users and wanted to have the same tag. But I guess that would be covered by bulk signing anyway and can actually be more trouble if you accidentally use the wrong tag.

Compiles for me, too with Qt 6.5.2 from tumbleweed.

Well the message is content-type multipart/mixed. For GpgOL to investigate the mail it needs to be multipart/signed oder application/encrypted or application/pgp-encrypted. (and some other things) But multipart/mixed is something that we don't take a second look at because this means "unencrypted mail with attachments."

In T6679#174951, @werner wrote:

The copy of the database we received for this case is not damaged. A possible problem might be insufficient rights to read the database. For example created with an Admin account and then later used by a different user.

Hi, my suspicion with the different tenant is that some middleware of yours is inserting something like "DANGER this could not be Virus Scanned by your super secure and expensive middleware" which then results in the mail beeing multipart/mixed instead of pgp/encrypted in the MIME type. Could you ask your communication partner with the problem to send such a mail to you and with CC to "andre.heinecke@demo.gnupg.com

Nevermind we clarified in chat that we would instead deprecate this API.

Btw. TBH I actually should read again about "explicit" in C++ I never really understood its necessity. :)

Thanks for the pointers. I just wanted to paste this as a differential so that it does not get lost in a stash somewhere on my system. I actually do not like this approach anymore. And do not want to commit it in this way. I would rather subclass or extend KAboutData with a verification option and then read from a QSettings style file instead of this Line based thing. For this I really think that an out of process call makes sense because the call is not to gpg but only to gpgv where we can just rely on the return code and even if we just patch it in having a GPGME dependency in KCoreAddons would be bad design IMO.

I have a bad patch for this. D567 But I think we need a better solution that works without libkleo and could live in KCoreAddons as a change to KAboutData so that we can reuse it better for T6594

Changed the task description to easier find it

Hi,
This is a classical support question. Please use one of the community channels under:
https://www.gpg4win.de/community.html
for this.

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.

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.

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?