onion proxy is already initialized by AppInitMain() function in init.cpp
The removed code contains the assumption that the proxy is local.
If it has been initialized to be remote and configured by using the -proxy option, the removed code was breaking the config.
Signed-off-by: Olivier Langlois olivier@trillion01.com
onion proxy is already initialized by AppInitMain() function in init.cpp
The removed code contains the assumption that the proxy is local.
If it has been initialized to be remote and configured by using the
-proxy option, the removed code was breaking the config.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
This code is there to set the onion proxy automatically when a local instance of Tor is available that torcontrol can communicate with, and make listen on a hidden service.
Removing it is not a good solution. It could however check if there is a proxy set up for wait, it does this onion already, and skip this code if so, instead of overwriting it.(gArgs.GetArg("-onion", "") == "". What exactly is the problem you’re having?
What I can think of is that you provided -proxy, which automatically sets -onion but isn’t detected here (this seems to be a bug).
If it has been initialized to be remote and configured by using the -proxy option, the removed code was breaking the config.
You likely want to set listenonion=0 in that case to prevent it from communicating with the local tor instance at all. Then this code is skipped.
9050 is used, while it has a connection to the Tor control socket so could directly ask what the SOCKS5 proxy port it is listening on is (GETINFO net/listeners/socks, I think, see control-spec.txt). Or bypass it if there isn’t any.
This code is there to set the
onionproxy automatically when a local instance of Tor is available that torcontrol can communicate with, and make listen on a hidden service.Removing it is not a good solution.
It could however check if there is a proxy set up forwait, it does thisonionalready, and skip this code if so, instead of overwriting it.(gArgs.GetArg("-onion", "") == "". What exactly is the problem you’re having? What I can think of is that you provided-proxy, which automatically sets-onionbut isn’t detected here (this seems to be a bug).If it has been initialized to be remote and configured by using the -proxy option, the removed code was breaking the config.
You likely want to set
listenonion=0in that case to prevent it from communicating with the local tor instance at all. Then this code is skipped.
Ok, I agree that removing the whole block might not be the right solution but testing that -onion is empty isn’t the correct condition neither.
My problem with this line is it that the onion proxy address is hardcoded to 127.0.0.1
Imagine that someone sets -proxy 192.168.1.2:9050 -torcontrol 127.0.0.1:9051
or perhaps something less surprising and or more common: -proxy 127.0.0.1:8050 -torcontrol 127.0.0.1:9051
I guess that the intent of the onion proxy setting code block is for the case where someone would have provided -torcontrol and have omitted to provide -onion or -proxy.
How about testing if it is set by calling GetProxy()?
My problem with this line is it that the onion proxy address is hardcoded to 127.0.0.1 Imagine that someone sets -proxy 192.168.1.2:9050 -torcontrol 127.0.0.1:9051
This is fixed in #15423. Feel free to review and/or test it.
thx. I will take a look