Richtext in Pseudo-mailing-lists #91

Closed
opened 2013-03-31 23:40:27 +02:00 by ghost · 9 comments
ghost commented 2013-03-31 23:40:27 +02:00 (Migrated from github.com)

The text prepended in pseudo-mailing-lists, "Message ostensibly from", causes the textEditInboxMessage qTextEdit widget to interpet all messages as text, due to QTextEdit::setText being used.

The text prepended in pseudo-mailing-lists, "Message ostensibly from", causes the textEditInboxMessage qTextEdit widget to interpet all messages as text, due to QTextEdit::setText being used.
ghost commented 2013-03-31 23:41:08 +02:00 (Migrated from github.com)

Possible fixes might be to use QTextEdit::setHtml() for all Broadcasts where the Address is in Subscriptions or Address Book, or when the first characters of the original body are "<html>" or "".

Possible fixes might be to use QTextEdit::setHtml() for all Broadcasts where the Address is in Subscriptions or Address Book, or when the first characters of the original body are "<html>" or "<qt>".
Atheros1 commented 2013-04-01 01:48:18 +02:00 (Migrated from github.com)

Currently this behavior is on purpose. It is unfortunately possible to imbed base64 encoded images right in the body of a message and have it show if you use setHTML. This makes me nervous because anyone could broadcast very inappropriate material over a pseudo-mailing list and it would display to all of the users.

Currently this behavior is on purpose. It is unfortunately possible to imbed base64 encoded images right in the body of a message and have it show if you use setHTML. This makes me nervous because anyone could broadcast very inappropriate material over a pseudo-mailing list and it would display to all of the users.
Scopelabz commented 2013-04-01 15:35:58 +02:00 (Migrated from github.com)

When it comes to security I'd also say that enabling html by default -could- be used to spread inappropriate stuff and I am also thinking about stuff other than images, like scripts, iframes and similar.

A solution which worked okay for me was to implement an additional button that allows me to toggle between plain text and rich text display mode so I am in full control of what I want to see and what not. It kind of resembles the "Display images" button which some traditional email clients use. (See below)

bitmessage_modded

Like I previously said to delicatebits (via Bitmessage :-) ) a 3rdparty client like walrus, which uses the official api could be a solution. That way users could still use the vanilla client while - on the other hand - being able to view richt content as well.

When it comes to security I'd also say that enabling html by default -could- be used to spread inappropriate stuff and I am also thinking about stuff other than images, like scripts, iframes and similar. A solution which worked okay for me was to implement an additional button that allows me to toggle between plain text and rich text display mode so I am in full control of what I want to see and what not. It kind of resembles the "Display images" button which some traditional email clients use. (See below) ![bitmessage_modded](https://f.cloud.github.com/assets/4026857/323880/04a6a032-9ad1-11e2-9101-c18ba9d1b968.png) Like I previously said to delicatebits (via Bitmessage :-) ) a 3rdparty client like walrus, which uses the official api could be a solution. That way users could still use the vanilla client while - on the other hand - being able to view richt content as well.
ghost commented 2013-04-02 01:55:24 +02:00 (Migrated from github.com)

@Scopelabz Qt's richtext is based on a subset of html4, http://qt-project.org/doc/qt-4.8/richtext-html-subset.html, so scripts and iFrames shouldn't be a concern. What little testing I've done showed it wasn't possible to include remote files, either.

@Atheros1 You're right, a user can't trust the content of mailing lists like they can with regular broadcasts and person-to-person messages. I've submitted a pull request that I think addresses your concerns.

@Scopelabz Qt's richtext is based on a subset of html4, http://qt-project.org/doc/qt-4.8/richtext-html-subset.html, so scripts and iFrames shouldn't be a concern. What little testing I've done showed it wasn't possible to include remote files, either. @Atheros1 You're right, a user can't trust the content of mailing lists like they can with regular broadcasts and person-to-person messages. I've submitted a pull request that I think addresses your concerns.
Scopelabz commented 2013-04-02 21:23:46 +02:00 (Migrated from github.com)

@delicatebits
Ah thanks for the info, I wasn't quite aware of that since I never used rich text stuff in Qt (I mostly develop headless software).

@delicatebits Ah thanks for the info, I wasn't quite aware of that since I never used rich text stuff in Qt (I mostly develop headless software).
Atheros1 commented 2013-04-06 00:03:46 +02:00 (Migrated from github.com)

So this is all implemented in the Master branch on Github. Would anyone who has international characters in various places (like the time?) be able to test?

So this is all implemented in the Master branch on Github. Would anyone who has international characters in various places (like the time?) be able to test?
ghost commented 2013-04-06 04:01:24 +02:00 (Migrated from github.com)

Adding <br> to the end of every line, L#4606 breaks formatting and embedded images.

Adding `<br>` to the end of every line, [L#4606](https://github.com/Bitmessage/PyBitmessage/blob/master/bitmessagemain.py#L4606) breaks formatting and embedded images.
ISibboI commented 2013-04-06 13:37:43 +02:00 (Migrated from github.com)

The date on the network status tab seems to be displayed correctly.

The date on the network status tab seems to be displayed correctly.
Atheros1 commented 2013-04-06 18:04:35 +02:00 (Migrated from github.com)

Thank you, I fixed L#4606

Thank you, I fixed L#4606
This repo is archived. You cannot comment on issues.
No Milestone
No project
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Bitmessage/PyBitmessage-2024-12-08#91
No description provided.