This patch adds code for connecting through SOCKS5 proxies. It was
primarily written for use with TOR, so there are some open issues:
* it only allows to make proxy requests with full hostnames; ipv4/ipv6 is
not supported
* GSSAPI authentication (which is mentioned as mandatory in RFC 1928) is
not implemented
* plaintext authentication is untested
To use it
* set 'proxy_type' to 'socks5'
This patch adds code for connecting through HTTP proxies. Open issues are:
* support of proxy authentication
* a possible DOS due to the usage of g_io_channel_read_line_string() which
does not allow to specify a maximum length of line.
To use this method:
* set 'proxy_type' to 'http'
This method implements the string + string_after mechanism implemented by
previous irssi versions.
To use, set
* proxy_type to 'simple' or keep it empty
* string + string_after in the known ways
This patch creates a hook into the net_connect*() methods which call a
method to connect to a proxy.
Previous solution to send certain strings in the normal IRC dialog was
some kind of hack as most proxies require some kind of negotation.
E.g. HTTP proxies sent a 'HTTP/1.0 200 Connection established' HTTP header
and clients have to wait for it. Else, sent bytes of the following IRC
login will be dropped silently.
With old method, it is also impossible to tunnel SSL IRC connections
through the proxy as proxy speaks plain text or a special protocol while
e.g. 'CONNECT ... HTTP/1.0' will be encrypted with key of IRC server.
There are further enhancements possible: the whole net_connect stuff
should be made asynchronously. Currently, only the hostname is resolved
in the background (which makes little sense of local proxies usually).
The userhost Irssi uses for line splitting can in some cases be wrong,
for instance when a proxy is used or when a server cloaks the hostname
without telling the client. Now Irssi always assumes the userhost is of
maximum length. 10 for username (common value) and 63 for hostname (in
RFC 2812).
this fixes a crash due to illegal memory access that can occur if
something is printed to the screen on the "terminal resized"
handler. It is not clear to me whether this race condition can be
triggered by external incoming messages, but it might be better safe
than sorry.
while the last patch did stop /path/.xxx from turning italic, it also
stopped any other /emphasis/ from becoming italic. correct this by
testing for ispunct, so spaces are valid italic terminators
the colour 0 was broken by the extended colours patch because it needs
an explicit bit check (lower bits will be false since it is 0)
Thanks to lhynes for the report
Fixes Github issue #97https://github.com/irssi/irssi/issues/97
Fix proposed by ailin-nemui, built and tested on Debian Jessie using
0.8.15 source, tested by GeertHauwaerts as well.
