The reason for this is the change to Kleopatra that the columns are configurable ( 4847fcc27afc8101752de82b0dd1f5fee027695d ). In the process we added additional columns like origin and to hide the "summary" column that the line edit for the recipients use we gave it an index number that was higher then our internal column count.

Thank you very much for the report. I can see this problem myself. It is strange because the code for that has not changed since 3.1.7 so it must be some sideeffect.

I'm having a very similar problem in 3.1.5! Randomly, when I try to view a PGP-signed e-mail, nothing shows, both on preview panel and when I open the message.

File->Save As now works for crypto mails. It saves the encrypted message.

This works now, the hidden BeforePrint Event enabled us to detect when a print happens and the old code to do blocking decrypts enabled the actual printing.
We also do not print "our categories" (encrypted message, level x trust),... anymore, even in quick print.

I did forget to mention that the key I'm using is 4096 bit long

I was creating a tar archive with 7-Zip on my Windows 10 machine. After the creating was completed I was encrypting the archive like so:

Just to clarify, you were able to decrypt and extract it without error? Which tool did you use to extract the tar archive?

The change in message class did not help.

Works for me

I did encrypt the file myself with the version mentioned above.

Maybe the file was encrypted with a version of gpg4win-3.1.5? We had a serious bug there that sometimes files were corrupted. See: T4332

My understanding of this issue and the fix for it is that Outlook with exchange detects that our mails are S/MIME mails. As the attachments are modified by us outlook wants to save the changes on move. This fails because it can't do the crypto. Leading to the error. This also happens when such a mail is closed.

We did not remove the "<>" from the content id. This worked for the first display but when forwarding they got doubled and it broke.

We only supported SHA-1 signed OCSP requests. Fix will go into 2.2.16.

The code had the assumption that a content-id
could only exist on an attachment for HTML mails as it otherwise
does not make sense.

I was able to reproduce this when I forwarded the mail after opening it in a new window. Somehow that appears to influence it.

You need to update the public key and convey it to the sender. This will solve the problems. You should also ask the sender to update their software so that an MDC is always used regardless of the flag.

Yes, very exactly indeed: It's GPgOL within gpg4win-3.1.1... ;) But you're right, the key itself is a legacy key, created back in 2001 with a commercial PGP Solution and later on the key was "spiced up" cipher-wise...Goal ist to get everybody (also the sender) to gpg4win-3.1.7, but how can I achive not having lots of eMails which one will never be able to decrypt?

Do you know which software the sender uses for encryption? That software may simply ignore the preferences or the sender also encrypts to a legacy key using a software which does not force the use of an MDC. Sometimes keys are generated with gpg but used with other software - without updating the preferences of the keys.

There will be no full solution for this. However, the next release should in general work due to a 400ms delay we use after spawning the viewer. This is configurable; see rG7e5847da0f3d715cb59d05adcd9107b460b6411b.

Actually the temp file is created but because the photo viewer is run as a detached process and gpg keeps on running, the temp file has been removed by gpg at the time the photo viewer tries to open it. Ooops. The correct behaviour would be to wait for the photo viewer to be finished. We use

The problem could be narrowed as follows: According to Mailvelope Add-on, GnuPG must be installed for smart card support. Screenshots show that GnuPG is not recognized by Mailvelope. Of course actual versions off all programs were installed. Therefore, e-mails sent out ecrypted with public key work fine, because the public key is stored in Mailvelope. Is the encrypted message arrives and should be decrypted. Mailvelope does not find GnuPG and therefore, no private key. I´ll send some screenshots to you.

That was obvious. rG6fc5df1e10129f3171d80cf731f310b9e8d97c26 fixes this.

When doing a "gpgsm --with-validation -k foo" (assuming you have a cert foo) gpgsm now goes into a loop and prints the certficates that match "foo" over and over again. I have not tested if it was caused by this change but I think it is likely.

Smartcard support is a big advantage of using the GnuPG backend and it should work of course.

I imported 39 certificate files at once with Kleopatra with about 700 certificates and it worked. Took a long time though so It would be nice if Kleopatra would show a progess indicator or some indication that the import is running. But this is a different issue.

Or a better tl;dr; When you send mails without "inline" option everything is fine and standardized. The problem is that the old version of GpgOL that your college uses is too stupid to handle this ;-)

Yes your colleague should or basically needs to upgrade. 2.2.3 is very outdated. There are security issues that were fixed by then etc.

In T4515#125651, @aheinecke wrote:

Hi,

What client does your colleague use so that you have to use PGP/Inline?

That format where the attachment is it's own PGP Encrypted file is very problematic. You basically have mutliple signature and encryption states. An attacker can easily remove or add attachments to the message. The attachment name is leaked. etc. Also see: https://wiki.gnupg.org/PgpPartitioned

Our opinion is that if you really _have_ to use PGP/Inline that you must do so manually using Kleopatra's notepad and Encrypted files.

I am a bit unsure if I just close this as "Wontfix" or move it to Wishlist. I think for now I go with Wishlist but do not expect that feature soon. At least until maybe some really important use case comes up.

Anyway, thanks for your feedback. It is always valuable to know what users would like to have.

Best Regards,
Andre

What client does your colleague use so that you have to use PGP/Inline?

The last lines that the process currently holding wrote in the log:

To reproduce this issue I started Kleopatra with an empty GNUPGHOME and imported 10 S/MIME certs at once (which spawns a gpgsm process each) with enabled logging.