[Pidgin] #12562: Pidgin IRC does not handle SSL blocks of > IRC_INITIAL_BUFSIZE correctly (was: Pidgin appears to expect each SSL packet to contain exactly one line of text)

[Pidgin]

#12562: Pidgin IRC does not handle SSL blocks of > IRC_INITIAL_BUFSIZE correctly
-------------------------------------------------+--------------------------
 Reporter:  Stmeter                              |        Owner:  elb
     Type:  defect                               |       Status:  new
Milestone:                                       |    Component:  IRC
  Version:  2.7.3                                |   Resolution:     
 Keywords:  SSL inspircd packets gnutls openssl  |  
-------------------------------------------------+--------------------------
Description changed by elb:

Old description:

> This problem was discussed on the IRC (http://pastebin.com/jcWdPz4U). elb
> approved that it is a bug.
>
> When using Inspircd 2.0 and sending large SSL packets(4096 bytes)
> containing many lines, Pidgin is taking about 3 minutes to finish reading
> the introduction from the server. Pidgin times out until the server sends
> a ping, which then makes the socket readable, which explains the 3
> minutes. It essentially has to do with buffer handling.
>
> If the IRCD sends one line at a time, the socket will remain readable
> because SSL only eats one packet at a time. The main area where this
> problem exists is the whole irc_input_cb_ssl, which probably needs to be
> redone.

New description:

 This problem was discussed on IRC:

 elb: when that function was written, it copied the behavior of
 irc_input_cb directly[[BR]]
 elb: irc_input_cb manipulates the TCP socket directly ... so if there's 3
 bytes of data in the socket and you read 2 bytes, the socket has 1 byte
 left on it and the input cb will be called again the next time around the
 mainloop[[BR]]
 elb: but irc_input_cb_ssl does *not* manipulate the TCP socket
 directly[[BR]]
 elb: if 3 bytes of data come in in one SSL block, and you read two bytes,
 the SSL library will have read all 3 to give you those 2 (plus whatever
 else came along with them -- padding, etc.)[[BR]]
 elb: so you read two bytes, then hand control back to the mainloop ... and
 it doesn't iterate again[[BR]]
 elb: the next IRC_INITIAL_BUFSIZE (or whatever the constant is) of bytes
 won't be read until *more* data comes in

 When using Inspircd 2.0 and sending large SSL packets(4096 bytes)
 containing many lines, Pidgin is taking about 3 minutes to finish reading
 the introduction from the server. Pidgin times out until the server sends
 a ping, which then makes the socket readable, which explains the 3
 minutes. It essentially has to do with buffer handling.

 If the IRCD sends one line at a time, the socket will remain readable
 because SSL only eats one packet at a time. The main area where this
 problem exists is the whole irc_input_cb_ssl, which probably needs to be
 redone.

--

-- 
Ticket URL: <http://developer.pidgin.im/ticket/12562#comment:1>
Pidgin <http://pidgin.im>
Pidgin