[Pidgin] #17038: IRC conformance issues: backend sends initial USER and NICK messages out of order, and supplies bogus mode.

[Pidgin]

#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