another-im/libtacky

Watch

Fork 1

SOCKS5 proxy and Tor per account #4

Closed

ann wants to merge 0 commits from feat/socks5-proxy into develop

ann commented

2026-10-15 16:52:23 +00:00

Owner

An account's connections can go through a SOCKS5 proxy or Tor. quackchat (moving to libtacky from upstream tacky) depends on this per-account feature, which upstream tacky had.

What changes

tacky-core: stream::socks5 adds RFC 1928 CONNECT with RFC 1929 login. The target is named to the proxy (address type 3) and never resolved locally. The handshake runs inside the dial's step and stop. Reply codes map onto the dial's kinds, and a failure names the proxy.
- Config.proxy and the new tacky_stream_config_t fields: every candidate goes through the proxy, WebSocket included. Under a proxy the SRV endpoint skips both the SRV lookup and host-meta and dials domain:5222. Nothing falls back to a direct connection.
- net::socket::connect_via and tacky_net_socket_new_via give a host's own protocols the same path. The browser build refuses a proxy.
Bindings, session and HTTP: stream connect takes a proxy key and socket::connect a -proxy option. The session takes -proxy. tacky::http's spec takes proxy, which every dial of a transfer, redirects included, goes through. The one-call verbs take -proxy.
Account: account add/set take proxy (socks5://[user:pass@]host:port) and tor. The store holds two nullable columns, added in place to older files. proxy.tcl builds the route. Tor defaults to 127.0.0.1:9050, with a random login per account so each account gets its own circuits (IsolateSOCKSAuth).
- The route reaches conn, bareconn and the registration session. A change reconfigures a live client and restarts an enabled account's connection.
- Every HTTP transfer of the account (uploads, downloads, avatars by URL, the OAuth exchanges, XEP-0455) takes the route. The host transfer backend refuses such a transfer instead.
What a route rules out: calls and group calls are refused, and an incoming propose is rejected with unsupported-transports and logged as missed, because ICE would carry media around the proxy. Direct file transfers lose the data channel and fall back to IBB.
Docs: schema, make gen-api, the wire.tcl typing for tor, and an RFC 1928 row in features.md.

Gate run in the container on this branch

Tcl unit suite: 184 suites, 5,403 cases, 5,393 passed, 0 failed, 10 skipped (datachannel lane).
tacky-core cargo test --features tacky-keyring/fast-kdf: every suite passes, including cov_transport this time.
check-api, check-headers and check-native-neutral pass. make headers regenerated tacky_ffi.h, and the DOAP file is unchanged.

Not run

The webrtc media lane of the Tcl suite.
The Prosody and ejabberd integration rigs.
Any test against a real Tor daemon.

An account's connections can go through a SOCKS5 proxy or Tor. quackchat (moving to libtacky from upstream tacky) depends on this per-account feature, which upstream tacky had. **What changes** - **tacky-core**: `stream::socks5` adds RFC 1928 CONNECT with RFC 1929 login. The target is named to the proxy (address type 3) and never resolved locally. The handshake runs inside the dial's step and stop. Reply codes map onto the dial's kinds, and a failure names the proxy. - `Config.proxy` and the new `tacky_stream_config_t` fields: every candidate goes through the proxy, WebSocket included. Under a proxy the SRV endpoint skips both the SRV lookup and host-meta and dials `domain:5222`. Nothing falls back to a direct connection. - `net::socket::connect_via` and `tacky_net_socket_new_via` give a host's own protocols the same path. The browser build refuses a proxy. - **Bindings, session and HTTP**: `stream connect` takes a `proxy` key and `socket::connect` a `-proxy` option. The session takes `-proxy`. `tacky::http`'s spec takes `proxy`, which every dial of a transfer, redirects included, goes through. The one-call verbs take `-proxy`. - **Account**: `account add`/`set` take `proxy` (`socks5://[user:pass@]host:port`) and `tor`. The store holds two nullable columns, added in place to older files. `proxy.tcl` builds the route. Tor defaults to 127.0.0.1:9050, with a random login per account so each account gets its own circuits (IsolateSOCKSAuth). - The route reaches conn, bareconn and the registration session. A change reconfigures a live client and restarts an enabled account's connection. - Every HTTP transfer of the account (uploads, downloads, avatars by URL, the OAuth exchanges, XEP-0455) takes the route. The `host` transfer backend refuses such a transfer instead. - **What a route rules out**: calls and group calls are refused, and an incoming propose is rejected with `unsupported-transports` and logged as missed, because ICE would carry media around the proxy. Direct file transfers lose the data channel and fall back to IBB. - **Docs**: schema, `make gen-api`, the `wire.tcl` typing for `tor`, and an RFC 1928 row in `features.md`. **Gate run in the container on this branch** - Tcl unit suite: 184 suites, 5,403 cases, 5,393 passed, 0 failed, 10 skipped (datachannel lane). - tacky-core `cargo test --features tacky-keyring/fast-kdf`: every suite passes, including `cov_transport` this time. - `check-api`, `check-headers` and `check-native-neutral` pass. `make headers` regenerated `tacky_ffi.h`, and the DOAP file is unchanged. **Not run** - The webrtc media lane of the Tcl suite. - The Prosody and ejabberd integration rigs. - Any test against a real Tor daemon.

ann added 3 commits

2026-10-15 16:52:23 +00:00

tacky-core dials through a SOCKS5 proxy (RFC 1928, with RFC 1929's login): stream::socks5 connects to the proxy by the transport's own resolve and RFC 8305 dial and asks it for the target by name (address type 3), so the name is resolved there and never here, an address literal going as one, all within the dial's step and given up on at the stop; the proxy's replies become the dial's kinds (4, what Tor answers for a name that does not resolve, is resolve; 2 and 5 refused; 6 timeout) and the failure names the proxy, so a dead proxy does not read as the server refusing. The stream's Config takes a proxy (tacky_stream_config_t's proxy_host, proxy_port, proxy_username, proxy_password, the browser build refusing one), every candidate goes through it, WebSocket included, and through it the SRV endpoint looks nothing up, neither SRV nor host-meta, both of which would ask around the proxy, and dials the domain on 5222; nothing falls back to a direct connection. net::socket gains connect_via and the C ABI tacky_net_socket_new_via for a host's own protocol. The login is never in Debug and is wiped on drop. Tests: the handshake against a proxy played on loopback (no login, a login, a refused login, a method we cannot do, every reply code, a bound name or IPv6 address read past, a silent proxy timing out, a stop, a dead proxy named), streams of each kind through a forwarding proxy, SRV through a proxy asking neither the lookup nor host-meta, the FFI constructor, and the config's new layout. 489832bc49

The Tcl side carries a proxy to every dial: tacky::core::stream connect takes a proxy key ({host port ?username? ?password?}, "" none) and tacky::core::net::socket::connect a -proxy option of the same shape, the login's bytes zeroed after the call; the session has -proxy and puts it in the dial dict; tacky::http's spec has a proxy key that every dial of a transfer, its redirects' included, goes through, and the one-call verbs take -proxy. Tests: a GET through a proxy played on the event loop in front of the loopback server, the host named to it, a proxy that cannot reach the host and a dead one failing the transfer in their words with nothing dialled around them, the verbs, a proxy without a port refused; the spec's defaults now list proxy. 2193b2419d

An account can go through a SOCKS5 proxy or Tor: account add and set take proxy (socks5://[user:pass@]host:port, parsed and refused at the door) and tor, the store keeps them as two nullable columns added in place to older files, and get answers them. proxy.tcl makes the route: the proxy as given or, with tor, Tor at the proxy or at 127.0.0.1:9050 with a random login per account for the life of the process, so each account rides circuits of its own (Tor's IsolateSOCKSAuth) and the exit sees no name. endpointOptions hands the route to conn, bareconn and the registration session alike, a change reaches a live client and restarts an enabled account's connection so nothing stays up on the old route, and the transfer object gives an account's every HTTP transfer the same route (uploads, downloads, avatars by URL, the OAuth exchanges, XEP-0455's status), refusing it on the host backend, which could not honour it. Calls and group calls are refused while a route is set, and a propose that rings is rejected with unsupported-transports and logged missed, because ICE sends UDP a SOCKS5 CONNECT cannot carry and the media would go around the proxy; a direct file transfer has no data channel then and rides IBB, inside the stream. features.md gains the RFC 1928 row. Tests: the parser, the endpoint, Tor's logins, what is stored and refused, the route on the conn and on a live client, the transfers' route, the session's dial dict, the call, group call and data-channel refusals; the mocks take -proxy and the endpointOptions expectations name it. 8e756669fc

ann referenced this pull request from a commit

2026-10-15 17:34:38 +00:00

Merge PR #4 "SOCKS5 proxy and Tor per account" (Pavel R.'s feat/socks5-proxy, 8e756669) into the rc5 line: tacky-core dials through a SOCKS5 proxy (RFC 1928 with RFC 1929's login), the bindings, session and tacky::http carry it, and an account's proxy and tor columns route its link and its transfers. The one conflict, account set's tail, where rc5 pushes the connection columns to a live client and the PR restarted on a route change, is resolved into one path: proxy and tor join connection_columns, PushConnectionColumns takes the route from before the write, configures the client with endpointOptions (which now carry -proxy) and, when the route moved on an enabled account, restarts the connection whatever its state, otherwise keeping rc5's rule of dialling again only when offline; RouteChanged is left to say the new route in the log, so a write that changes the host and the proxy of an offline account connects once, not twice.

ann referenced this pull request from a commit

2026-10-15 17:34:38 +00:00

An account set or added with -enabled 1 and a route in the same write dials once, through the route, and a route that moves behind a proxy ends the calls under way (PR #4 review, defects 1 and 7). set ran enable inside its field loop, before the proxy and tor columns were committed, so `account add -tor 1 -enabled 1` dialled straight out and then again through Tor once the route change restarted it; set now disables before the commit, enables after it and after PushConnectionColumns, whose own connect it suppresses then, so an enabled account given -enabled 1 and a new route restarts once. RouteChanged, given the client already configured, now leaves every group call (groupcall LeaveAll, what OnClosing runs) and ends every call (calls EndAll, likewise) when the route goes from direct to proxied, since their ICE media would otherwise go on around the proxy. The mock conn records the -proxy of each dial (get_connect_routes). Tests in test_proxy: the add and the set dialling once through the route, the enabled account restarted once, a call in progress retracted before the restart; all three fail on the merge before this. test_proxy 21, test_account 61, test_calls 82, test_groupcall 140 passed.

ann referenced this pull request from a commit

2026-10-15 17:34:38 +00:00

An account's HTTP transfer whose route cannot be made is refused, not sent directly (PR #4 review, defect 2). transfer.tcl's ProxyRoute caught any error from the account's route and answered "", so a Tor login that could not be made (tacky::crypto::random absent: proxy.tcl never required tacky::crypto) sent uploads, downloads and the OAuth exchanges around the proxy the user asked for. Only an installation request, an account that is not there and a backend without its account component now answer ""; an account's own failure raises out of request and the transfer is refused with it. proxy.tcl requires tacky::crypto where it makes the login, and the TlsOverrides doc comment the PR had split goes back above its method. Test in test_proxy: a route that raises refuses ProxyRoute and the request (before this the request went out as t1); test_proxy 22, test_transfer 30, test_http_proxy 5 passed.

ann referenced this pull request from a commit

2026-10-15 17:34:38 +00:00

A proxy's login is blanked in every trace (PR #4 review, defect 3). `account set -proxy socks5://user:pass@host:port`, its JSON key on the wire and the route dict conn is configured with as -proxy carry the proxy's password, and redact.tcl did not know the key, so a failing set or a throw beneath a configure put the login in the log and in <BackgroundError>. proxy joins secretKeys and valueKeys: the option and the JSON key are blanked whole, and the value wherever else the trace or its message quotes it. Test in test_bgerror: the URL, the route dict and the JSON key blanked, the login nowhere in the trace, the message or the log (fails before this); test_bgerror 15, test_log_secrets 3, test_media_redact 8, test_conn_console 14, test_oauth 35 passed.

ann referenced this pull request from a commit

2026-10-15 17:34:38 +00:00

A call refused because the account goes through a proxy reaches the user as notify <MissedCall> (PR #4 review, defect 4). The PR's reject path for a propose under a proxy only ran Finish missed, which writes the row and <Ended>; on rc5 a missed ring reaches the user through calls:<Missed> (NoteMissed), which notify turns into <MissedCall>, as the busy path does, so someone calling an account on Tor was never shown. The path now calls NoteMissed with reason proxy before Finish, and the schema's MissedCall reason doc names proxy (gen-api: methods.tcl unchanged). Test in test_calls: the refused propose is a calls:<Missed> on the bus with reason proxy and leaves no call (fails before this); test_calls 83 passed.

ann referenced this pull request from a commit

2026-10-15 17:34:38 +00:00

An in-band registration dials through the proxy or Tor it is given (PR #4 review, defect 5). The PR gave the registration session a -proxy and its bareconn the route, but register connect took no proxy and its Endpoint built the would-be account's row without one, so the session's -proxy was always "" and a user registering on a server they reach only over Tor dialled it directly. register connect now takes -proxy and -tor, refused at the door by account ValidateFields as account add's are, and Endpoint hands account endpointOptions a row with both, keyed by the domain, so under Tor the registration rides a login of the domain's own (a backend-less tacky_register parses and routes them itself). Schema: register connect's proxy and tor args (since 1.0.0-rc5); gen-api types tor bool in methods.tcl; check-api clean. Test in test_register: a proxy with its login and Tor at 127.0.0.1:9050 on the domain's login reach the session's dial, and an http:// proxy is refused (fails before this); test_register 69 passed.

ann referenced this pull request from a commit

2026-10-15 17:34:38 +00:00

The data channel's disco feature follows the account's route (PR #4 review, defect 6). jinglefile.tcl advertised urn:xmpp:jingle:transports:webrtc-datachannel:1 once, at construction, so a route set on a built client left peers offered a transport the proxy rules out, and one cleared kept them from it until a restart. jinglefile gains AdvertiseDataChannel, run at construction and from account.tcl RouteChanged on a built client, which adds the feature while HaveDataChannel holds and removes it otherwise through caps' new removeFeature (the held list and the disco answer, so the ver is made anew for the restarted connection's presence). Test in test_proxy, with the media backend claiming a data channel: the feature there, gone with a proxy set, back with it cleared (reads 1 1 1 before this); test_proxy 23, test_jinglefile 67, test_caps 65, test_disco 11, test_account 61 passed.

ann referenced this pull request from a commit

2026-10-15 17:34:38 +00:00

tacky-core's SOCKS5 login reads the version byte of the proxy's RFC 1929 reply (PR #4 review, defect 8). authenticate looked only at the status byte, so a peer answering the login with anything at all and a zero second byte passed as a proxy that took it. The reply's version must now be RFC 1929's 1, or SOCKS's own 5, which some proxies send and curl reads past; any other is an Io failure naming the proxy, "not a SOCKS5 login reply (version N)". Tests in socks5/tests.rs: a reply of version 9 fails so (passes the login before this), one of version 5 is read as curl reads it; the socks5 unit tests 14 passed.

ann referenced this pull request from a commit

2026-10-15 17:34:38 +00:00

The README's figures are the tree to be tagged v1.0.0-rc5: tools/stats.py --readme in the container with the main .git mounted, the coverage figures still those of the 2026-10-07 run. The gate on this tree: the Tcl unit suite 5,507 cases, 5,505 passed, 0 failed (one test_omemo_devices.tcl case failed under the gate's load and passes 44/44 alone three times) and the datachannel lane 5,497 passed, 0 failed on the PR #4 branch that this tree fast-forwards to; check-api, check-headers and check-native-neutral; the Rust suites with cov_transport passing this time; the integration suites on Prosody 13 166 passed, 0 failed, 19 skipped and on ejabberd 26.09 170 passed, 0 failed, 15 skipped, both with the OMEMO bot beside the server.

ann commented

2026-10-15 17:35:50 +00:00

Author

Owner

Merged into develop by hand as b526f78b (feat/socks5-rc5 onto release/rc5), in v1.0.0-rc5 (d1cca8e5), with eight follow-up commits from the review (4ec68d20 set dials after the commit and the route change ends calls, 03d8b9f5 transfer refuses on a route error, 7b16862b proxy redacted, d437e329 the proxy reject notifies a missed call, 9f83c291 register connect -proxy/-tor, e72c8827 the data-channel feature follows the route, 8e62aa6a the RFC 1929 version byte). The account.tcl conflict with rc5's PushConnectionColumns is resolved as one path: proxy and tor are connection columns, a route change restarts an enabled account once.

Merged into develop by hand as b526f78b (feat/socks5-rc5 onto release/rc5), in v1.0.0-rc5 (d1cca8e5), with eight follow-up commits from the review (4ec68d20 set dials after the commit and the route change ends calls, 03d8b9f5 transfer refuses on a route error, 7b16862b proxy redacted, d437e329 the proxy reject notifies a missed call, 9f83c291 register connect -proxy/-tor, e72c8827 the data-channel feature follows the route, 8e62aa6a the RFC 1929 version byte). The account.tcl conflict with rc5's PushConnectionColumns is resolved as one path: proxy and tor are connection columns, a route change restarts an enabled account once.

ann closed this pull request

2026-10-15 17:35:50 +00:00

ann referenced this pull request from a commit

2026-10-25 23:27:10 +00:00

AUDIT-2026-10-25 #4 (Medium): one accept of a Telegram secret chat offer at a time, and only its answers act: mtproto.tcl keeps the offers being accepted (Accepting, set by accept, cleared by the answer, an error, Drop and a disconnect), so a second accept while the first's dh-config or <accept> is in flight is refused with errorcode {MTPROTO BUSY} instead of sending a second <accept> with another g_b; OnAcceptDh and OnAccepted act only for the accept in flight and an offer still offered, so a late or duplicate answer no longer drops a chat this device owns (accepted-elsewhere, item-not-found) nor replaces its key with one Telegram never got; and accepted-elsewhere naming this device's own resource (an earlier accept whose answer was lost with its key) ends the chat at the gateway (<discard>) and drops the offer rather than listing the chat as another device's. The schema's mtproto accept notes name BUSY. Tests: test_mtproto.tcl mtproto-a-second-accept-is-refused-while-the-first-is-in-flight, mtproto-an-answer-to-an-accept-no-longer-in-flight-changes-nothing and mtproto-accepted-elsewhere-by-this-very-resource-is-not-another-device (each fails before: two <accept>s went out, the late answer raised over the ready chat, the chat was listed as owned elsewhere by garden).

ann referenced this pull request from a commit

2026-10-27 00:26:42 +00:00

schedule: the scheduler is our own server or a gateway we are registered with, never any domain that says it schedules, and resubmits, releases and cancels lose nothing, from the audit of 2026-10-26 (/data/another-im/audit-2026-10-26-libtacky.md #1 Critical, #3, #4, #5; S5 of the schedule sub-report): a chat's domain is its scheduler only when the account is registered with it (in the roster at to or both, roster transportUser's rule) and its disco#info names a gateway identity and the feature (Registered, Trusted); any other domain, a plain server running mod_schedule included, is never asked, and a <changed/> from anyone but our server or a registered gateway about a chat at itself is ignored before anything is asked or read, so a federated domain can no longer hold, drop or plant our scheduled messages or make us send disco#info to domains it names; a redirect is followed only to a registered gateway; a listed row is read with omemo decryptListed, side-effect free. Resubmit writes the msg column (it wrote row, which the table has not, so send_now of a refused submit and an edit of one never taken always threw). A submit left waiting by a lost answer goes again at the next sign-in or resumption only after its chat's list answered (SubmitWaiting, RecheckThenSubmit), which takes the item back by origin-id, and an edit made meanwhile is put to that item by <replace/> (PutChange) instead of a second submit. An item gone from a list, or a cancel answered item-not-found, keeps its row hidden as released for its copy (30 days) instead of deleting it when its time was ahead, which lost a send_now from another device or a release racing a cancel from this device's history; a <changed what='cancelled'/> naming the item drops it at once. docs/protocol/schedule-0.md §3, §4.4, §5, §6, §7 and §8 say so. Unit tests in test_schedule.tcl, each failing without the change but the cancelled-headline guard; test_schedule 37 of 37 in the container. Nothing changes for tackygram, which is a registered gateway with identity gateway/telegram; anotherim-server mod_schedule could also answer a submit repeating one of the user's origin-ids with that item.

ann referenced this pull request from a commit

2026-10-27 00:26:42 +00:00

ROBOTS.md and docs/features.md: the scheduler rule and the side-effect-free reading of listed payloads from the audit of 2026-10-26 (#1, #4, #5): a chat's domain schedules only as a gateway the account is registered with (roster to/both, disco identity gateway, the feature), else the account's server, and no other domain is asked; a listed OMEMO payload goes through omemo decryptListed alone, on copies; a waiting submit goes again only after its chat's list answered, and a row gone from a list is kept released unless a cancel says otherwise.

ann referenced this pull request from a commit