Encrypted containers on pages which add HTML to the container

[derWhity]

Some pages (e.g. Facebook) add HTML tags to the messages/comments/etc. you post. If such a post is GPG-encrypted, an error is displayed, when webpg tries to decrypt it (see screenshot).

It would be nice to filter out any HTML markup between the -----BEGIN PGP MESSAGE----- and -----END PGP MESSAGE----- markers before trying to decrypt.

[jayze]

I've installed the 0.9.4 and there the formatting is better, not yet what it should be :)
For example, where at the end of every line a
tag appears, you don't see the
tag anymore, but now a newline is displayed, which causes the decryption to break.

[kylehuff]

WebPG makes a best effort to detect erronous/extrenous HTML tags within PGP blocks -- this is, however, only best erroft, as it HTML within a PGP block is perfectly sane.

I believe the root issue is that PGP data is not being placed in appropriate containers (such as pre tags) that preserve the formatting and prevent markup from being inserted. Granted, I am aware that not all content posting sites support such mechanisms.

@jayze can you provide me with more information of what you are referring to? What I mean is, how is the PGP data being presented? (i.e. textarea, HTML element, etc.) Also, if you think a sample would help, please include that.

[sukima]

Would it be possible to define best effort as: Verify the content between the PGP marks, if it fails strip HTML from the content and verify again. That way you could catch a good portion of the false positives. It isn't perfect but better.

[jayze]

Hi,

Perhaps a screenshot can clarify what I see.

As you can see, the PGP encrypted message is captured correctly, but the BR's are interpreted making it impossible to decrypt.

Ps this is eg on Jira software of atlassian.

[kylehuff]

Would it be possible to define best effort as: Verify the content between the PGP marks, if it fails strip HTML from the content and verify again.

That is a possibility. I'm not sure how expensive that would be on pages with many PGP data parts.

I think, at least for the time being, having a reproducible test case that illustrates these types of issues would be most helpful.

Ps this is eg on Jira software of atlassian.

Yes, but what kind of HTML element is the element that contains the data? In reality, all HTML could be stripped from PGP MESSAGE blocks, since they don't contain the plaintext. That would work around this particular issue, however, it would not solve the issue for cases that are inline.

[jayze]

@kylehuff What exactly do you want me to provide ?

This is the structure how (eg in Jira) the message is build up.

[kylehuff]

@jayze that is what I was looking for. It is being displayed incorrectly because it is contained within the wrong type of HTML element. It should be a in a "pre" element, either system or user provided.

To reiterate, I believe in these particular cases we should be able to work around the issue by stripping all HTML elements from the message (because that type of PGP message doesn't have any plain-text), but that doesn't make the presentation correct. Stripping the HTML off of fields that contain white-space sensitive data and expecting it to validate is a little like having XML in presented in such a field and expecting it to validate. (I'll get off my soapbox now...)

In summary, my plan is to implement the following:

• IF the PGP data type is "PGP MESSAGE" or "PGP PUBLIC KEY BLOCK", WebPG will automatically strip all HTML from the message
• IF the PGP data type is "PGP SIGNED MESSAGE" (contains plain-text), WebPG will perform best efforts to remove extraneous HTML markup, but should probably slap somebody for doing it wrong.