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?

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.

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?

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).

Importing certificates now raises the mainwindow the same way as previously "--import-certificates" would have done. To have it raised even before the job is started gives the widget a bit of a backdrop with the progress and result.

Ah and we should remove the help button in case the PDF Group config help is not available (e.g. on normal linux systems) because opening the kleopatra handbook does not make sense when there is no documentation about groups in there :)

I am giving this wishlist priority for now.

For the record I tested it on Windows that this now saves the config when logging out.

No problem ;) Sorry for my snarky reply. Hope it worked for you now.

Noticed this issue was still open. This was resolved.

I think that fixes the biggest issue here as long as kleo is not just killed it should save the current configuration state. Maybe we should add it in some more places explicitly, too where many things are stored in the config, like with the certifydialog?

😂 Skandal! Ein BUG!: "Möchten Sie die Installation ohne Administrator-Rechte fortfahren?" und Sie sagen "Nein". Ja dann brechen wir ab weil sie eben *nicht* fortfahren wollen.

This could have something to do with our changes to g4wihelp.c to adapt to the new plugin API.

You can install Gpg4win without admin rights. It requests "Highest available" rights by default to be installed into the protected Program Files (x86) folder. When you are not in the Administrators group It will install into your home directory much like firefox does. Any maybe if you don't want to leave a footprint installing Gpg4win on the System (without admin rights) where you don't have admin rights is kind of beside the point. You either leave a footprint by the installation or you could just use the installed Gpg4win there.

Regarding PIN, they should be set first.

1. A temporary Admin / User PIN is be generated and stored in gpg-agent.
2. Then the keys are created as mentioned above.
3. The user is asked to set a new PIN and Admin PIN for the card.
4. Optionally set a RESET CODE

For generate new keys we see four use cases

1. Create card and backup card. -> Creates at least two cards with the same keys. Keys might be stored in ram: TODO: Add subtask
2. Full backup of all keys - Allows for copied cards at a later time.
3. Only backup encryption Key. - There is a backup of the encryption key on the computer.
4. No backup - Keys will be generated on the card.

Yes i think we need something like that, maybe shorter like this message is (VS-NfD compliant) encrypted and this message was (VS-NfD compliant) signed by "user.name@foo.bar" as a single line each, with "Details" available. And then in details show some more information like who the message was also encrypted to, ideally with the user ids when we have the keys in the keyring already and not the fingerprints of the keys. Or maybe just a status indication icon like we have in GpgOL which provides more information when you click it or as a tooltip. At the very least we need to make sure that this cannot be faked by e.g. HTML Mails :) so it needs to be removed a bit from the actual mail body.

I would like it if we could show the result list widgets above or below the message contents in the message viewer. Maybe shortened to a single line and then you can expand it to see the details.

A bit related: T6656 when I look at the web interface of an account that uses GpgOL I see these files everywhere. And they should then also be handled by kleopatra but for that they need some file extension that I can link to kleopatra.