Page MenuHome GnuPG
Create Task
Maniphest T4796

GpgOL should hide "legacy display" parts when it encounters them
Testing, NormalPublic
Actions

Description

It's great to see that GpgOL 2.4.4 can correctly handle an obscured subject line when rendering an encrypted message.

However, it looks like it is explicitly displaying the legacy-display part for some messages that it doesn't need to display. see the protected headers spec for a specific algorithm for detecting a legacy display part.

I'm attaching screenshots from the protected headers test corpus that demonstrate the issue. You can see the problem if the first line of the body appears to be "Subject: BarCorp contract signed, let's go!"

Unnecessary rendering of legacy display for pgpmime-sign+enc+legacy-disp.eml:

and for pgpmime-layered+legacy-disp.eml:

note that it *does* sometimes hide the legacy display part, for some messages, including unfortunately-complex -- that's good! -- but maybe this points to some internal inconsistency:

Revisions and Commits

rO GpgOL
rO72e95d2539e2 Improve protected headers handling

Related Objects

Event Timeline

dkg created this task.Dec 24 2019, 11:27 PM
• aheinecke claimed this task.Jan 8 2020, 2:00 PM
• aheinecke triaged this task as Normal priority.
• aheinecke added a subscriber: • aheinecke.

note that it *does* sometimes hide the legacy display part, for some messages, including unfortunately-complex -- that's good! -- but maybe this points to some internal inconsistency:

That is not intentional :-D

Before I can hide the legacy display part we would need to handle all the other headers besides subject, too. So this issue is a trap to get me to implement more of the protected headers spec. :-) (yeah yeah, I'll do it)

• aheinecke changed the task status from Open to Testing.Jan 16 2020, 1:19 PM

Display now looks good to me in all cases. We still keep the subject when a reply / forward is done, but that is the same as before. To do this properly I would have to actually do the protected headers sending,.. as then I could automatically flag such a message to be sent with protected headers. But that would be a new feature and I rather work on properly doing BCC sending as the next privacy enhancing feature.

• aheinecke added a commit: rO72e95d2539e2: Improve protected headers handling.Jan 16 2020, 3:21 PM
dkg added a comment.Jan 16 2020, 10:42 PM

thanks for the fix, @aheinecke ! can you post screenshots of the changes? or do you have a nightly build i could test?

If you want to try making screenshots, you can access the test messages at imap://bob@protected-headers.cmrg.net/inbox with any password as well, as detailed in my post to LAMPS.

• aheinecke added a comment.Jan 17 2020, 3:04 PM

An updated build is available here: https://files.gpg4win.org/Beta/gpgol/2.4.6-beta3/

With documentation how to use it here: https://wiki.gnupg.org/TroubleShooting#Manually_update_GpgOL_to_a_beta

I have the test mails imported in one of my test accounts but I started to make the screenshots and it was a bit tedious to ensure that the screenshots are good. ;-)

dkg added a comment.Feb 5 2020, 12:45 AM

Thanks! taking screenshots is definitely tedious. I just redid the screenshots for all the sample pgp/mime messages with GpgOL 2.4.6-beta3, and i can confirm that it looks like you've resolved the matter.

Thanks for that fix!

I haven't tested the same behavior against the S/MIME samples (i'm just testing Outlook's native S/MIME). Do you expect the same behavior for S/MIME too? do you want me to test that?

dkg mentioned this in T4837: outlook declines to render internal part when Content-Disposition: inline on actual body.Feb 5 2020, 12:46 AM