[Pidgin] #17038: IRC conformance issues: backend sends initial USER and NICK messages out of order, and supplies bogus mode.
Pidgin
trac at pidgin.im
Thu Jun 9 18:18:11 EDT 2016
#17038: IRC conformance issues: backend sends initial USER and NICK messages out
of order, and supplies bogus mode.
----------------------------------+------------------
Reporter: isd | Owner: elb
Type: defect | Status: new
Milestone: | Component: IRC
Version: 2.10.12 | Resolution:
Keywords: standards-compliance |
----------------------------------+------------------
Description changed by isd:
Old description:
> Per rfc2812, the IRC client protocol dictates that the client is supposed
> to initialize the connection by sending:
>
> 1. (Optionally) a PASS message
> 2. A NICK message
> 3. A USER message
>
> Observationally, pidgin does (3) and then (2), and the mode specified in
> (2) makes no sense wrt the spec.
>
> Steps to reproduce:
>
> 1. Add an account to pidgin with IRC protocol and (examples) nick foo,
> username Bob, connecting to localhost port 6667 (with no TLS). Then run:
>
> {{{
> nc -l 6667
> }}}
>
> And tell pidgin to connect. Netcat prints:
>
> {{{
> USER foo * localhost :Bob
> NICK foo
> }}}
>
> Section 3.1 dictates that these messages should be in the opposite order.
> Additionaly, per section 3.1.3 the mode parameter being passed as '*' is
> supposed to be a numeric value with specific semantics, full details
> described in the rfc.
>
> I've got a tool I'm working on that is currently having to work around
> these conformance bugs.
New description:
Per rfc2812, the IRC client protocol dictates that the client is supposed
to initialize the connection by sending:
1. (Optionally) a PASS message
2. A NICK message
3. A USER message
Observationally, pidgin does (3) and then (2), and the mode specified in
(2) makes no sense wrt the spec.
Steps to reproduce:
1. Add an account to pidgin with IRC protocol and (examples) nick foo,
real name Bob, connecting to localhost port 6667 (with no TLS). Then run:
{{{
nc -l 6667
}}}
And tell pidgin to connect. Netcat prints:
{{{
USER foo * localhost :Bob
NICK foo
}}}
Section 3.1 dictates that these messages should be in the opposite order.
Additionaly, per section 3.1.3 the mode parameter being passed as '*' is
supposed to be a numeric value with specific semantics, full details
described in the rfc.
I've got a tool I'm working on that is currently having to work around
these conformance bugs.
--
--
Ticket URL: <https://developer.pidgin.im/ticket/17038#comment:1>
Pidgin <https://pidgin.im>
Pidgin
More information about the Tracker
mailing list