-
Notifications
You must be signed in to change notification settings - Fork 352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Native Proxy support for Irssi #148
Conversation
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).
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 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 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 the code and rules to build the various proxy methods.
Warnings when using socks5: |
01:20 [proxy] |
{ | ||
struct _network_proxy_http *self = container_of(proxy, struct _network_proxy_http, proxy); | ||
|
||
g_free((void *)self->password); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: No need to cast here and elsewhere for g_free()
.
To avoid producing warnings, I will have to change a few structs to use "char" instead of "const char" as well. Is this what you want? :) |
Hi,
|
What Nei said. |
Thanks for the feedback :) I'll see what I can do |
I need some help with the inheritance modeling, I don't know how it works.. :-| |
I'm going to add a few things to Nei's comment. How about the UI? We shouldn't add new features unless there's a good use-case for the feature. I think there's a very good use-case for supporting multiple proxies, but I think we must ensure that our use-cases are correct. The three scenarios I see is:
User InterfaceListening available proxy options:
Adding a new proxy:
Specifying a proxy for a given connection:
Specifying a proxy for all connections:
If a given connection have a proxy server that's different than the Discuss! |
Oh, and more importantly: we need to keep in mind that some people using Irssi really should never connect to IRC over anything but Tor, so it's important that if, for example, a user have specified that his |
Just mentioned on #irssi that it would be cool to have support for external proxies (ala ssh's |
Just an opinion, but -host shouldn't be used to specify server to connect to since it's used to specify the interface to bind to elsewhere in irssi(/server), no need to add to the confusion |
Good point, thanks :-) |
This lives in https://github.com/irssi/irssi/tree/orphaned/native-proxy now |
See the changes in TODO. There are warnings produced while running it and there are also some usage of "attribute((packed));"
Nevertheless, I would like feedback :)