ARM architecture support.

[ProKn1fe]

This allow only run exists tor files (set TorSharpSettings.ZippedToolsDirectory and TorSharpSettings.UseExistingTools), because fetch and run code must be entire rewritten. Arm version can be downloaded here https://sourceforge.net/projects/tor-browser-ports/files/ but they have different folder structure and it require to repack .tar.gz archive to get it work.

For example tor-browser-linux-arm64-12.0.3_ALL.tar.xz: Tor and Data folders are located in tor-browser\Browser\TorBrowser. Repack example: tor-linux-aarch64-12.0.3.tar.gz

Maybe create nuget package to provide repacked tar.gz archives? Or rewrite current code to support auto download (those archive size larger that x86 bundles because they contains entire browser) and different folders structure?

Tested on Radxa Rock-5B board.

var settings = new TorSharpSettings
{
    PrivoxySettings = { Disable = true }
};

using var httpClient = new HttpClient();
if (RuntimeInformation.ProcessArchitecture == Architecture.Arm64)
{
    settings.ZippedToolsDirectory = Path.Combine(AppContext.BaseDirectory, "Tor");
    settings.UseExistingTools = true;
}
else
{
    var fetcher = new TorSharpToolFetcher(settings, httpClient);
    await fetcher.FetchAsync();
}

TorProxy = new TorSharpProxy(settings);
await TorProxy.ConfigureAndStartAsync();

var handler = new HttpClientHandler
{
    Proxy = new WebProxy(new Uri("socks5://localhost:" + settings.TorSettings.SocksPort))
};
HttpClient = new HttpClient(handler)
{
    Timeout = TimeSpan.FromSeconds(300)
};
HttpClient.DefaultRequestHeaders.Add("User-Agent", "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36");

[joelverhagen]

Interesting concept. I really like the idea of supporting more platforms (similar to the macOS gap tracked here: https://github.com/joelverhagen/TorSharp/issues/41).

For ARM64, there are a couple of additional challenges:

1. No CI support for ARM64 (https://github.com/actions/runner-images/issues/5631) so automated testing would be harder/impossible.
2. No official distribution of ARM64 Tor. The binaries linked are unofficial. I wonder if the trustworthiness is the same. Tor, perhaps more than other binary distributions, should be a trusted executable with well-understood provenance.

Regarding repacking the archive format: it looks like the (unofficial) ARM64 binary distribution is the "browser bundle" rather than the "expert bundle". TorSharp used to handle both of these formats (see this diff as an example https://github.com/joelverhagen/TorSharp/commit/673a359bb7c621ded8d34cbb64fe924cfa4a31f4#diff-a6e7e09d5cdd0cb97db6eed09e1d45e7df7475fed489629a708c9321a1a3d7b5) so that could be reintroduced for ARM64. In other words, repacking should not be necessary.

I don't have an ARM64 PC/board so I wouldn't be able to drive this implementation to completion.

If you'd like to bring this support into the main TorSharp version, I have a couple of ideas:

1. Add an option called "AllowUnofficialDistributions" or something like that which folks need to opt in to (manually set from the default false to true) to enable the ARM64 fetcher to download from this unofficial place.
2. Modify the Tor fetcher to bring back the browser bundle compatibility removed in https://github.com/joelverhagen/TorSharp/commit/673a359bb7c621ded8d34cbb64fe924cfa4a31f4, but just for ARM64.
3. Disable Privoxy on ARM64 since I don't see an ARM64 build for it (example: https://github.com/joelverhagen/TorSharp/blob/release/samples/NativeSocksProxy/Program.cs)

[ProKn1fe]

Yes i think i can provide full arm support.

1. I agree with AllowUnofficialDistributions. I think also for any linux system it is possible try to find if system already have installed or running tor? For example i install tor on my board and it already running as service. The only difference is default port 9050 not 19050.

apt install tor
whereis tor
tor: /usr/bin/tor /usr/sbin/tor /etc/tor /usr/share/tor /usr/share/man/man1/tor.1.gz
whereis torrc
torrc: /usr/share/man/man5/torrc.5.gz
Also torrc in /etc/tor/torrc

If it already running it show config path and it possible to parse port from config:

ps aux | grep tor
debian-+   14662 10.1  0.2  39012 34660 ?        Ss   21:01   0:00 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0

2. Oh i see there is easy way to parse sourceforge repository.
3. It's actually also exists in repository and it can be detected if system already have it.

apt install privoxy
whereis privoxy
privoxy: /usr/sbin/privoxy /etc/privoxy /usr/share/privoxy /usr/share/man/man8/privoxy.8.gz
ps aux | grep privoxy
privoxy    15049  0.0  0.0   5468  3528 ?        Ss   21:07   0:00 /usr/sbin/privoxy --pidfile /run/privoxy.pid --user privoxy /etc/privoxy/config

Something like (both false by default):

public class TorSharpSettings
{
    public bool DetectSystemHaveTor { get; set; }
    public bool DetectSystemHavePrivoxy { get; set; }
}

If tor in system detected but cannot run skip it and go by default way. Also i see tor and privoxy configs are auto generated so it make system tor usage more easy.

[joelverhagen]

Using the system-wide Privoxy or Tor would be great. It's roughly supported in Privoxy, like this: https://github.com/joelverhagen/TorSharp#privoxy-fetched-by-torsharp-fails-to-start-try-executablepathoverride

This could be extended to work with Tor just like you mentioned.

One tricky part is that the process and config should still be managed by TorSharp, it's just a matter of using the binary available on the system. So I guess you can try depending on tor in the path and then use tor -f <torrc> to pass the generated config file to tor instead of using the default system one (which I assume exists for distro-provided tor).

You could also opt for this required system-installed Tor/Privoxy on ARM64 if you don't want to do the unofficial tool fetcher. I think the tool fetcher is very convenient so it's up to you how far you want to go.

[joelverhagen]

Oh and whatever new options you add, feel free to set the defaults to something that is nice and helpful on the ARM64 system. We shouldn't mess with existing platform defaults but new platforms can have new defaults that are useful and make sense on that plat.