• Bug#518235: the case for proxy support

    From Manny@21:1/5 to All on Mon Apr 7 20:00:01 2025
    * Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de> [2010-03-29 08:03]:

    dunno; there was neither a response on the maillist nor in the bugtracker. Perhaps, proxies are such an exotic feature that nobody needs them.

    The simplest users and use cases can escape the need for proxies, but
    I will highlight a real need for proxy support in irssi.

    ① Bitlbee is a piece of middleware that typically runs on the local
    machine. If you run “torsocks irssi”, the local ports are
    unavailable. So you cannot simultaneously use torsocks to reach cloud
    servers while having some local windows connected to Bitlbee.

    ② Torsocks requires trust. Torsocks does not force an app to use
    Tor. It’s merely an ugly hack whereby an app incidentally uses a
    standard library that has been swapped. But it’s the apps choice to do
    so. An app running on Torsocks /could/ ignore the standard lib and
    directly manually make network connections that bypass Tor. Not
    necessarily out of malice but a design choice. Users have to inspect
    the code if they want confidence that the app is using the normal
    network design pattern. A proxy setting gives users confidence that
    their app will use the expected network. It still requires trust, but
    ignoring a user’s proxy instructions would be bluntly malicious and
    users more readily trust that blatant malice is not in play than the
    accidental variety.

    Torsocks is hack; and it falls short in the bitlbee scenario. One hack
    that works for Bitlbee users is this:

    $ socat -T9999999 -s TCP4-LISTEN:12345,ignoreeof SOCKS4A:127.0.0.1:libera75jm6of4wxpxt4aynol3xjmbtxgfyjpu34ss4d7r7q2v5zrpyd.onion:6697,socksport=9050,ignoreeof &
    $ socat_pid=$!
    $ irssi
    $ kill ${socat_pid}

    It’s a bit tedious to have a separate socat tunnel running for every
    cloud server needed. But it works. Until a tor circuit goes down. So
    suppose you have conversations going on 4 different IRC servers (thus
    4 socat processes), and one of the circuits goes down? Socat is
    killed. It’s extra tedious to track down which socat process needs to
    be relaunched in order to reconnect. Alternatively, users can /quit
    and rerun their script, but that interrupts all their chats.

    It’s quite a mess. And a bit surprising that as old as irssi is, there
    is no proxy capability given the nature of IRC clients.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)