Bug 136542
| Summary: | gaim's IRC driver does not handle multiline messages gracefully | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Daniel Reed <djr> | ||||||
| Component: | gaim | Assignee: | Warren Togami <wtogami> | ||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | |||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | rawhide | CC: | eblanton, lschiere+bugs, mark, stu, triage, wtogami | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | bzcl34nup | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2008-05-07 00:01:48 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
the irc protocol doesn't allow multi-line comments. i'd argue that sending multiple messages is the correct, and more readable than embeding a literal \n in the message. This report is valid, although it is not a bug report, it is an RFE. I tried to mark it as such, but I cannot. I thought we had CTCP quoting at one time, but it appears we indeed do not. I'll put that on the list of things to tackle, but it's not a high priority. To quote what I apparently said when I wrote the current CTCP parser: /* Note that this is NOT correct w.r.t. multiple CTCPs in one * message and low-level quoting ... but if you want that crap, * use a real IRC client. */ The current implementation doesn't do anything incorrect, I should point out, it simply does not implement all of CTCP. As CTCP is not core IRC (and, in fact, not even standardized in any real way), I don't see this as a huge deal. I swear, CTCP and DCC were designed by gradeschool kids. Ethan The IRC protocol does not disallow the concept of multiline messages, nor does it have requirements that make it impossible to implement. The CTCP specification, published circa 1991, includes one possible way to implement multiline messages: By quoting newlines with a special delimiter. The message: Hi there!\nHow are you? becomes: Hi there!\020nHow are you? which is sent to the server as: PRIVMSG victim :Hi there!\020nHow are you?\r\n A client that receives the character \020 as part of a message is expected to examine the next character. \020r should be treated as \r; \020n should be treated as \n; \020\020 should be treated as a literal \020; and \0200 should be treated as \0. This bug is filed because gaim does not dequote \020r and \020n as \r and \n (resp.). What it would do with those characters is not the issue: I would be fine with gaim simply treating embedded newlines as spaces, but I would prefer if gaim could be made to treat an embedded newline the same way it treats a <br> in its AIM/ICQ mode. However, the end result should be that only the sequence \020\020 would be rendered as the special * character (showing 0010). Thanks. Created attachment 105616 [details]
low-level CTCP dequoter, new CTCP parser, inline CTCP dequoter
This seems to work for me. To test the specific functionality, sign on to an
IRC server in gaim, then telnet to the IRC server on port 6667. If you are
signed on as "victim" in gaim, type the following in telnet:
PRIVMSG victim :line^AVERSION^A 1^Pr^Pnline ^APING 1234^A2
It should show up as a CTCP request VERSION, a CTCP request PING 1234, and a
two-line message:
<actor> line 1
line 2
It may be important add two more components: One part to keep stacked CTCP
requests from causing you to send multiple replies, and one part to keep users
from being able to spoof messages (such as preventing multiline messages from
entering text into the left-most column).
Is this patch acceptable for the short term? (Can I include it in our packages until the functionality is available in a release?) The current release (1.1.0) still does not appear to handle embedded newlines
gracefully. Is there an alternate patch in the works, or can I feel free to turn
my original patch (attachment 105616 [details]) on for our builds?
Created attachment 109351 [details]
low-level CTCP dequoter, new CTCP parser, inline CTCP dequoter, second implementation
Upstream said they would rewrite this in a different way a while ago, are they still planning on doing so, or should we close this as WONTFIX? Upstream still wishes to rewrite this capability for future inclusion? FWIW xchat has had this for a while now. If upstream dislikes this capability then please say so, so we can close this WONTFIX. ping upstream upstream is still the same, even in the 2.0.0 betas. Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp |
User-Agent: Build Identifier: gaim's IRC driver does not handle multiline messages gracefully. Reproducible: Always Steps to Reproduce: 1. Join a gaim IRC client to #test 2. Join a naim IRC client to #test 3. Paste more than one line of text into the naim client and witness the gaim client Actual Results: gaim renders the multiline delimiter literally, as *r*n where * is a special graphic denoting the hexadecimal value of the CTCP escape character (x0010): <n> This is a first line*r*nThis is a second line. <n> This is a second message. Expected Results: gaim should render the embedded newline in a pleasing way, such as: <n> This is a first line This is a second line. <n> This is a second message. [http://www.irchelp.org/irchelp/rfc/ctcpspec.html] ***************** LOW LEVEL QUOTING ***************** Even though messages to and from IRC servers cannot contain NUL, NL, or CR, it still might be desirable to send ANY character (in so called "middle level messages") between clients. In order for this to be possible, those three characters have to be quoted. Therefore a quote character is needed. Of course, the quote character itself has to be quoted too, since it is in-band. M-QUOTE ::= '\020' (Ie a CNTRL/P). When sending a middle level message, if there is a character in the set { NUL, NL, CR, M-QUOTE } present in the message, that character is replaced by a two character sequence according to the following table: NUL --> M-QUOTE '0' NL --> M-QUOTE 'n' CR --> M-QUOTE 'r' M-QUOTE --> M-QUOTE M-QUOTE When receiving a low level message, if there is a M-QUOTE, look at the next character, and replace those two according to the following table to get the corresponding middle level message: M-QUOTE '0' --> NUL M-QUOTE 'n' --> NL M-QUOTE 'r' --> CR M-QUOTE M-QUOTE --> M-QUOTE If the character following M-QUOTE is not any of the listed characters, that is an error, so drop the M-QUOTE character from the message, optionally warning the user about it. For example, a string 'x' M-QUOTE 'y' 'z' from a server dequotes into 'x 'y' 'z'. ... - --- Example 1 ----------------------------------------------------------------- A user (called actor) wanting to send the string: Hi there!\nHow are you? to user victim, i.e. a message where the user has entered an inline newline (how this is done, if at all, differs from client to client), will result internaly in the client in the command: PRIVMSG victim :Hi there!\nHow are you? \K? which will be CTCP quoted into: PRIVMSG victim :Hi there!\nHow are you? \\K? which in turn will be low level quoted into: PRIVMSG victim :Hi there!\020nHow are you? \\K? and sent to the server after appending a newline at the end. This will arrive on victim's side as: :actor PRIVMSG victim :Hi there!\020nHow are you? \\K? (where the \\K would look similar to OK in SIS D47 et. al.) which after low level dequoting becomes: :actor PRIVMSG victim :Hi there!\nHow are you? \\K? and after CTCP dequoting: :actom PRIVMSG victim :Hi there!\nHow are you? \K? How this is displayed differs from client to client, but it suggested that a line break should occour between the words "there" and "How".