Page MenuHome GnuPG

print preview tries to use wrong key for decryption
Closed, ResolvedPublic

Description

When trying to print an encrypted mail from the "main" view of outlook, and then selecting a different printer from the default one, the decryption of the print preview fails.

(At first, the decryption works, then, after changing the printer, the new decryption fails, and a "please wait.." will be printed)

Logging indicates that this second decryption tries to use the secret key of the sender (which usually is not in the key ring), so the decryption fails.
The same dialog, when opened from the "message's window" (i.e. not "main view of outlook") , works without problems.

GDecrypt/VeryfiResult; GPGME::DecryptionResult(GPGME::Error(0 (Success))
[...]
GPGME::DecryptionResult::Recipient(keyID: (Sender) , shortKEyId (Sender) ... status: GpgME::Error(117440529 (No sercret key)

I'm using Windows 10 Pro, MS Outlook 2016, and gpg4win 3.1.11 for this, reproducing a report (see external link)

Revisions and Commits

Event Timeline

FWIW, a log of the decryption process will always show the sender's key because a message is usually also encrypted to that one (--encrypt-to).

aheinecke triaged this task as Normal priority.
aheinecke added a subscriber: aheinecke.

Thanks, I can reproduce the problem. I'll look into it, printing mails is important for some ;-)

Outlook is a bit nasty here:

-> We get the BeforePrint event.
-> Then comes the ItemLoad of the preview.
--> We handle that correctly. And mark the Mail for printing.

Usually when you then print the next ItemLoad with the same entryID is the actual print.
When changing printers though the preview is unloaded. And the next ItemLoad is again a preview but without seeing the BeforePrint event.

I'll try to keep track of this but I just would wish outlook would provide proper print events.

aheinecke changed the task status from Open to Testing.May 15 2020, 3:11 PM

After looking at this for 4h I could not see a way to detect it better when a print job is done. So we now treat every ItemLoad of a mail after we have seen the BeforePrint event as a print.

This means: Decryption is done synchronously (blocking) and the categories are not added (as they should not be printed out). So this fix creates a new issue which I find smaller then this issue here. I'll open a Task with low priority for that.

3.1.12 was released with this.