Ok. So after further discussion. It is good that you kept a WKDRefreshJob copy :)

I do not really understand why this is necessary. The problem is that /nonfatal conflicts with our msi creation as there is no such equivalent in the wix toolset language.

I recently noticed that the old workaround by setting a kategory when it is not visible in the messagelist does not work on a default Outlook 2204 anymore. This raises the priority of this issue.

There must be something special with the message. Can you save the message to a file and use the command line to decrypt it? Is there anything special with it? Is it maybe a binary and not text? Although I tried decrypting random bytes with the notepad and it worked for me. Is the message very large? Anything unusual? Or does it even happen for you when you encrypt a short text to yourself and then decrypt it again?

The issue with rWe06c325a9a29 was that it linked in all breeze icons and nowadays would also link in all breeze-dark icons. Which increased the size of Kleopatra so much that there was no performance gain and the fallbacks were still checked. This might require a fix in Qt / Kiconloader not to use fallbacks and also to only resource up the subset of icons which we actually use and package.

In QGPGME which is used by GpgOL and Kleopatra we have solved this by loading the configuration only once and then reusing it. I see no need to change something in gpgconf here.

I have pushed the patch, but still it did not work for me properly over everything and I had to add --enable-install-gpg-error-config to libgpg-error. This was because of at least the 64 bit build of libassuan-master it picked up gpg-error-config from my host system. I then tried to add --with-gpg-error-prefix to the assuan call but that failed because it only looked for gpg-error-config in this prefix and not for any gpgrt-config and failed immediately with a command not found error.

In that case could you please attach a basic log from selecting an S/MIME Mail with S/MIME disabled? Activatable under GpgOL options / logging

I think there is a mixup here. I believe that you are experiencing https://dev.gnupg.org/T6192 (From 2019) which is a fairly recent regression and was discovered by our internal QA in September. As we did not get reports about this we only gave it low priority.

Thanks for the report, since you are using it on the command line and it works I assume that trust-model is set to tofu+pgp? Because in the Test code there is no context flag for tofu+pgp trust model.

I tend to close this as a duplicate.

Cool, I will try it out ASAP. You must have read my mind. Only yesterday evening I ran into problems because the current code in src/Makefile.am to symlink the static libs did not work on my new dev system with a lib64 layout and thought that I needed just a patch like this to fix it properly.

We need to understand the usecase here.

With a gcrypt not claiming compliance you should not get the status compliant or not but GnuPG should error out with forbidden.

This is because Kleopatra does not differentiate between invalid S/MIME and unverified OpenPGP certificates and we want to be able to encrypt to unverified OpenPGP certificates.

This is a support question and not a bug. You should ask such questions on the channels for Gpg4win, which does the Community support for GnuPG on Windows: https://www.gpg4win.org/community.html

I would give this low priority as we default to "S/MIME disabled" and this issue is no longer that relevant. But as it is a regression and I am pretty sure I know why it happens -> Normal.

I think it is more of a Kleopatra issue.

Yes I have to look at this again. This resize stuff is code in GpgOL, which was intended to trigger UI redraws / updates of Outlook. Because it otherwise would not show our current state but something in the cache. And there is no "Redraw UI" Api. The Resize trick is something I got from stack overflow but it should be only 20px (seriously smaller px values cause no redraw) But there is a bug here when it is maximized I think.

Another thing we noticed today is that the pgpOnly check that determines if S/MIME and PGP or only PGP is shown (The radio buttons at the top right corner) is done only at initialization. So if you import your first S/MIME certs it will still only offer PGP certs and no option to switch. Just as a note here instead of a different issue because it is mostly for testing but should be improved on an update.

Ok. Let us resolve this. The patch is in kconfigwidgets without a version marker and I already added a patch-next next to it for future versions of kconfigwidgets. Should be no problem to keep.

For what it is worth, I think that my patch is more standard compliant then yours because it checks if there is a partial CRL.

I think 289fbc550d18a7f9b26c794a2409ba820811f6b3 implemented this wish from 2016 :) @werner please read the full report and then close it as fixed if you agree. I find it a bit funny that we both came independently to the same conclusion, that it should be handled differently even if the standard says otherwise. Because the behavior from the standard does not make sense and is in contradiction to other parts where it says that each CRL must contain all revocations.

If you could try: https://files.gpg4win.org/Beta/gpgol/2.5.5-beta2/x64/ (Source tarball in the directory above, signed by my key) Doc for this can be found here: https://wiki.gnupg.org/TroubleShooting#Manually_update_GpgOL_to_a_beta

I think what I saw and reproduced (and now fixed) was a different issue though. 5fd467a00d3ffa6c1ca83e9a248f4c01d77bbe72 broke IMAP connections for GpgOL in general. So we definitely will make a new, at least minor GnuPG VS-Desktop release. But first we need to reproduce and also fix your issue.

Good news is that I can reproduce the bug in our testlab by connecting an account via IMAP to exchange. Our other IMAP tests have intermediates like dovecot. The fix for this will be fairly simple but first I wanted to ensure that we could reproduce it for future testing of releases as this is a case that should have been covered.

Hello,
many thanks for the detailed report, I have given it some time to analyze and think I understand it:

To clarify that I meant that the underlying problem is our current keylisting speed in Kleopatra I have opened T6206.

In T6195#163175, @werner wrote:

keyboxd has nothing to do with this, it merely makes the lookup of keys a bit faster. The computation of the WoT itself takes long and there is no shortcut for it. Fortunately most users don't have a deeply meshed WoT with dedicated revokers etc., thus for them things are fast in the standard configuration.

I agree with that task. Errors should be logged but not exposed to the user. I like the decryption / verification audit log we have now for some years (quite new) which allows users to view the stderr of gpgme jobs. Something like that -> Perfect. I think we need this for Import also and basically for every job. If you had an idea, maybe in the status bar or so, to indicate that more error information would be available. That would be my dream solution.

Just for your understanding, it this output would say "COMPLIANCE 23" anywhere in it, Ingo and me should look at this issue, if it does not that is something for Werner or Gniibe.

Could you please post the output of 'gpg --status-fd 1 --verbose --decrypt "Neues Textdokument.txt.gpg"' here? That would help us to pinpoint the issue.

No, I was just meaning that you should not have to disarm your logs when include data is not set.

Yeah the error would lie in here I think: