Skip to content

Add Tor support for Ethereum, fix clearnet image loads in Tor mode - #1479

Open
kroplabeskidu wants to merge 3 commits into
cypherstack:stagingfrom
kroplabeskidu:tor-eth-support
Open

kroplabeskidu wants to merge 3 commits into
cypherstack:stagingfrom
kroplabeskidu:tor-eth-support

Conversation

@kroplabeskidu

Copy link
Copy Markdown

ETH has been flagged as not Tor-ready because web3dart only takes an http Client, which has no proxy support. It does work with an IOClient around a dart:io HttpClient, and that can be pointed at the Tor SOCKS5 proxy with SocksTCPClient.assignToHttpClient, the same way the Solana RPC client is set up. So this adds Tor support for ETH and ERC-20 tokens: wallet RPC, the node connection test, the usual node tor/clearnet mismatch check, and torSupport => true.

While going through the other coins and Tor code paths I found a few more things:

  • Nano and Banano already send every request through Tor, and Fact0rn uses the normal ElectrumX client. They only lacked the torSupport flag, so users got the warning for nothing. I also set torEnabled on the Fact0rn default node, like Peercoin's.
  • The Stellar node test sent its first request over Tor but then built a StellarSDK without the proxied client, so the ledger query went out directly.
  • Image.network and SvgPicture.network ignore the Tor setting. Token logos, exchange/coin logos in the swap flow, CakePay card images, ShopinBit attachments and theme previews were fetched directly in Tor mode. I added TorAwareNetworkImage and TorAwareSvgNetworkLoader, which go through the existing HTTP wrapper, and switched all call sites to them. Like the rest of the wrapper, they fail instead of falling back to clearnet when Tor is enabled but not connected.

Epic, MWC and Xelis connect from their native libs with no proxy option, so they keep the warning.

One behaviour change: with Tor on and an ETH node set to clearnet-only, you now get NodeTorMismatchConfigException, same as Solana/Stellar.

I added a test that runs eth_blockNumber through a fake SOCKS5 server and checks that the hostname is sent to the proxy, plus one for the direct path when Tor is off. The full flutter test passes in the stackwallet-ci image (604 passed, 4 skipped), and the changed files pass the format check. A few of the touched files weren't formatted on staging yet, so their diffs include formatting changes.

web3dart was handed a plain http Client, so ETH and ERC-20 RPC could not
use Tor and the coin was flagged as not Tor-ready. Give it an IOClient
wrapping a SOCKS5-proxied HttpClient instead, the same way Solana does it,
and do the same for the node connection test.

Also add the usual node tor/clearnet mismatch check and set torSupport.
Nano and Banano already send every request through Tor, and Fact0rn uses
the regular ElectrumX client, so they only needed the torSupport flag.

The Stellar node test proxied its first request but then created a
StellarSDK with the default client, so the follow-up ledger query went
out directly.
Image.network and SvgPicture.network use their own HTTP clients and ignore
the Tor setting, so token logos, exchange and coin logos, CakePay card
images, ShopinBit attachments and theme previews were fetched directly
even in Tor mode.

Add TorAwareNetworkImage and TorAwareSvgNetworkLoader, which go through
the app's HTTP wrapper, and use them at all call sites.
@sneurlax

Copy link
Copy Markdown
Member

Just FYI we have been reviewing this, it's not being ignored

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants