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:

I do not have a mind to really analyze this today, but when the checkbox in the logging options for "include data" is not set. There should be no much as an IP Address or Fingerprint mentioned in the logs. This was important to me and if you find that there are issues with that it would be a different bug also.

We have tested this a lot of course. But I will have to analyze your logs. Thanks.

In T6111#160993, @ikloecker wrote:

Please give this a try on Windows.

:)

I agree. We have to get rid of auto check trustdb and such stuff. I always found that impossible to program around because it either takes a long time (check-trustdb) or it might return invalid results (no check).
The solution for this is keyboxd.

Real Passphrase is "test"

The workaround is easy: Change the passphrase , export, import and then set a longer passphrase again.

In T6014#163086, @ikloecker wrote:

In T6014#163083, @aheinecke wrote:

I think it is problematic that the WKD errors are shown to the user at all. Doing some random searches gives an error each time something can't be accessed.

Can you give an example other than the Syntax error issue? So far, I haven't seen any errors when doing random searches with ASCII-only "email addresses". I simply get zero results, but I don't see error messages, e.g. if the host cannot be found.

I think it is problematic that the WKD errors are shown to the user at all. Doing some random searches gives an error each time something can't be accessed.

There is probably an umlaut or special character in <domain> or <user> which makes the URL invalid. If I search for "test@ä.de" I also get Syntax error in URI.

--import [files]
       Import  the certificates from the PEM or binary encoded files as well as from signed-only messages.
       This command may also be used to import a secret key from a PKCS#12 file.

Mh, this has not changed anything for me. With GnuPG 2.3.8-beta32 i get either Invalid Object or no error at all. With this certificate

That would make sense on a Linux desktop. But my main use case for this is Windows. I have the feeling that more Linux users have a decent MUA.
If we had a MUA with good MIME Support then we would not need this feature at all. If a user has Outlook for example that could be used with GpgOL but not everyone has that. I know that some users decrypt such messages already with Kleopatra and then open the Output in Thunderbird. But again, if they had Thunderbird, they could use that with included PGP/MIME support.
Windows 10 has a default Mail app, but if you open a file with that it does not show it but asks you to configure an account.

Instead of using KDE for MIME parsing, and as I would also only do simple parsing we could use the mimeparser from gpgol. This also has the advantage that we do not open new attack surfaces as we already have that code in use. The mimedataprovider can already be compiled on Linux and used with a FILE, I did this to allow fuzzing for it. And the API implements the GpgME::DataProvider interface https://dev.gnupg.org/source/gpgol/browse/master/src/mimedataprovider.h and then just offers simple functions to access the parsed content.

For Gpg4win we will soon release a 4.0.4 Version that will contain the latest Kleopatra updates and GnuPG 2.3.x, but the 3.1.x series of Gpg4win is something that we only release in binary form as part of our Product GnuPG VS-Desktop.
The reason for this is that for VS-NfD there are some responsibilities for the supplier, and so the VS-NfD user needs a responsible supplier. We do not promise that for Gpg4win, which is the free community version anyone can download. If we would provide Gpg4win-3.1.24 also in binary form we would make it harder for us to argue that VS-NfD users have to purchase GnuPG VS-Desktop with the required support.

@ikloecker yes as mentioned in my response the current hints are only for symmetric.

Well it is good that we have it now and we should not remove it. But when asked I would probably have said that this dialog / page should be removed altogether. I would bet that if we did a user survey this dialog is not used at all. Or very very rarely.

I can confirm the fix.

I was looking for this when writing the update NEWS for the latest release and noticed that this has not been pushed yet. I really think that it would be nice to have that. Especially for Smartcard use cases.