works, a key with a revoked uid is accepted as VS-NfD compliant, VS-Desktop-3.1.27.0-beta44

works

Hint: When the user disabled GpgOL -> Automation -> Automatically secure messages in the configuration of GpgOL he could see the email body again.

I am downgrading this to wishlist. Even though I had worked on this a lot the regression risk is probably too high to fix this before GpgOL becomes obsolete.

Hier is a log file from GpgOL (+Code verfolgung)

I have seen that the rule is honoring the exclusions of Microsoft Defender but I do not know if one would need to exclude gpgol.dll or the gpgolconfig.exe / gpg.exe in this case. https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/attack-surface-reduction-rules-reference?view=o365-worldwide#microsoft-defender-antivirus-exclusions-and-asr-rules

Gpg4win 4.1.0 comes a slighly newer gpgol which should be tried before we continue. Set to low prioprity because this seems not to be easily reproducible.

The gpgme part has been done. Some minor changes in Kleopatra regarding the VERSION file checking would be useful.

As discussed with Werner, the initial default will be changed "guessed" in GPGME to avoid code duplication between libkleo and GPGME.

This should really be in the next release.

Putting up for grabs and removing Kleopatra tag since for Kleopatra users this has been fixed (unless they manage to trigger multiple separate concurrent imports in Kleopatra).

Hello Andre Heinecke,

I'm that user - only thing I can think of really is that I used the tool "O&O ShutUp10++" to restrict Win10 Settings. During the troubleshooting I reverted to the standard settings, but it made not difference.

As I assume that many people have HTML emails still turned on, and have no crashes, there probably are more conditions that have to be met to trigger this crash.

Hello Andre Heinecke,

My opinion here would be add the "import key from signature" and "put key in signature" in the automatition group of the main GpgOL config page and change the wording of "Import any keys included in Mails" to "Import keys from Headers and Attachments".

On Windows, a whitespace character followed by a number in parenthesis at the end of the file name is now stripped from the proposed output file name.

Thanks for the certificate, looks good as far as I can tell. I have trouble with CRL checks for your certificate as https://crl.sectigo.com/ does not work for me. But that should not be an issue when decrypting.

@ikloecker Well in the spirit of user friendlyness Kleo could assist the user by removing this added blurb. We already assist the user in using a different folder then the temporary folder for such files.

Hello Andre Heinecke,

@ikloecker You are right, I only thought of public key import. Then lets serialize this. Might even make for a nicer Progressbar if we count the outstanding files.

In T4505#166463, @aheinecke wrote:

I have an Idea. Can't we read all data into memory in Kleopatra (for Certificates this should be ok) and then give this to GPGME as a single data object. So that only one process imports multiple files?

In T4505#166390, @ikloecker wrote:

I really don't want to bypass gpgme and then parse the import results and all other status output of gpgsm ourselves. I'll go for Andre's suggestion and serialize imports of multiple files.

Please attach the certificate so that we can check what is problematic with that certificate. I am changing this issue to wishlist as the solution here will most likely be that we have to extend the S/MIME capabilities of Gpg4win.

I really don't want to bypass gpgme and then parse the import results and all other status output of gpgsm ourselves. I'll go for Andre's suggestion and serialize imports of multiple files.

I meant bypass the gpgme engine and call gpgsm directly. Maybe using gpgme's spawn engine. But I am not sure whether this is really a good idea. If we can find a way to pass multiple filenames to gpgsm --server that would be better. But requires updates to gpgsm.

@werner Do I understand correctly that by "It might be easier to bypass the gpgsm and run gpgsm directly" you mean using gpgsm in server mode? Or what do you mean with "bypass gpgsm and run gpgsm" (which seems contradictory).

With 100 concurrently running gpgsm processes they all try to get the lock for the keyring. And they need to do this several times and often also for the same certificate (fetched from an external resource to complete the chain). Not good. It might be easier to bypass the gpgsm and run gpgsm directly instead of adding a feature to gpgsm to directly import from many files.

Sure, we could do this. Shouldn't make the ImportCertificatesCommand much more complex than it already is.

Reopening this as there still seem to be ways to run into a deadlock as was reported in RT#13361. While I still think this points to some issue in gpgsm, when Testing this I found the behavior of Kleopatra to be wrong.

I don't see why this would be a Kleopatra issue. How is Kleopatra supposed to know that "mytestfile.txt (002)" isn't the original filename, but just the result of another program that's too stupid to properly resolve filename conflicts?

I updated *.m4 scripts in gogol:

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.

Hello, if I understand the issue correctly this issue is about saving a decrypted email as a file to a local disk and not to Outlook? We would like to save the mail as a file like a normal mail file.

For *.m4 scripts, I pushed changes to prefer gpgrt-config with *.pc files than *-config scripts (T5034).
Before the change, it was not coherent; gpgrt-config gpg-error is preferred to gpg-error-config (if available), but libassuan-config was used if available.
After the change, gpgrt-config is used to configure gpg-error and libassuan, etc.

@aheinecke Please show me how you configure your libassuan-master (and the output which detects host's gpg-error-config erroneously).

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.

Here is the Log-File.
No, this mails in private-folder and not shared.
We have reproduced this issue on some W10 and W11 Systems with last build from Outlook

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

no, SMIME was not activated, the error still appeared and only when the GPG plugin was completely deactivated could Outlook read SMIME properly

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.

The first report? In history, i know, on older versions, this issue was also exist and reportet.

Follow-up in reference:
https://dev.gnupg.org/T6258

Please note that gpg4win 3.1 is not anymore maintained.

Please note that gpg4win 3.1 is not anymore maintained. Gpg4win 4.0.4 is the currrent release and comes with the IMAP fix. We do not have a single GnuPG VS-Desktop customer using IMAP and thus having the fix only in the next VSD version seems to be okay.

"Fix IMAP access to encrypted mails" - patch still not applied in codebase 3.1.25 ...

PS
The problem is also active, if I send an encryptet (not signed) message to myself.
If I get mails from other people, wich are encryptet using smime and the same certtificate and signed by the sender, there is no problem. GpgOL works fine here.

This is the first report we have on such a problem despite of hundred thousands of users. "Triage" means that we need to look at a report to check its priority.

@werner , why set to "needs triage"? At this moment plugin must be disabled if customer read crypted SMIME E-Mails. So it is critical. disable checkbox "SMIME" will not work correct. Enable "SMIME" will only encrypt as Text, but some E-Mails have HTML.
We have this issue on all systems (Windows 10 and Windows 11)

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.

Hello,
I'm having the same issue here, and as I've an image in the signature of my emails the signature is not visible at all when I sign the messages.
The image attached seems to be well included in the attachments and the image is readable.
Thanks,
isundil

I did a build of Gpg4Win 3.1.24 with Andre's provided patch :-)

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.

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)
If you could enable data debugging though (Include Data) in a log. And send it to me

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:

Here some further investigations ...

Here is another Test:

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

Should i create a new log without "include data" ?

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.