linuxdcpp-team team mailing list archive

[eMTee <2071439@xxxxxxxxxxxxxxxxxx>]

- [2024-07-07 05:56:45] <cologic> regarding https://launchpadlibrarian.net/737080365/SXML_ChatMessage_fix.patch it looks reasonable to me at least. from discussion here 2024-06-20 through 2024-06-23 or so, the only thing I'd say is, "Buffer overflow" is often viewed as a security vuln/exploit thing, so here it's a bit misleading and probably disconcerting for people to read. better to use some other phrase about, e.g., some part of the XML being too long
- [2024-07-07 05:57:02] <cologic> I'm dubious also about the value of long messages anyway -- any examples in the wild?

I agree with change of the wording to something that represents more
exactly what happens here.

Also I put aside this patch because of the exact same reason - I want to
see the example in the wild before. This issue has been reported in the
dev hub but I have not been able to reach the reporter for a real world
example to test in.

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2071439

Title:
  Long and continous chat messages are not displayed at all or getting
  truncated in some cases.

Status in DC++:
  Confirmed

Bug description:
  The error actually happens when a ChatMessage has a html text element that contains a 65535+ character long continous text block, not broken by any (link or other) tag.
  Only a continous chat message text chunk of size of 64KiB+, without any links, URIs, etc... in it can produce this error. 
  In this scenario the whole block (or the whole message, if it consists of only one of such long block) is getting lost and a SimleXMLException error message is printed to the chat window.

  The problem is that parsing of content of this size is currently over
  the limits of SimpleXMLReader. It seems like some hubs allow such
  large messages though or their (feed or similar) bots may purposedly
  generate such large content in their normal operation.

  The maximum content length a RichTextBox can currently hold is 128 KiB
  but the default maximum protocol command length (512 KiB) allows even
  larger chat messages to reach the HTMLtoRtf process.

  One possible solution to the problem is to split any continous 64KiB+
  message values inside the html element to less than 64 KiB long pieces
  by embedding empty <span> tags into them.

  Another solution is to add a new option to SimpleXMLReader that would
  - double the maximum output value/content size allowed
  - and handle output buffer overlow errors more gracefully
  so the already parsed content up to the (now extended) size limit is not getting lost even when the message is still too long.

  Included a patch implementing the latter solution where it is set that
  only HtmlToRtf, which emits already processed and UTF-8 verified safe
  input data to the parser uses this new option.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2071439/+subscriptions