torcontrol: Launch a private Tor instance when not already running #15421

No description provided.

NOTE: This uses boost::process, but currently doesn't have anything to check that it's actually available.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #19561 (refactor: Pass ArgsManager into functions that register args by S3RK)
• #19485 (torcontrol: Create also a V3 ed25519-V3 onion address. by Saibato)
• #19358 (net: Make sure we do not override proxy settings in hidden service. by Saibato)
• #19288 (tests: Add fuzzing harness for TorController by practicalswift)
• #15423 (torcontrol: Query Tor for correct -onion configuration by luke-jr)
• #14729 (correct -onion default to -proxy behavior by qubenix)

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 should be opt-in and not enabled by default, right?

Starting tor without the end-user asking for it explicitly is highly surprising. Also it could cause potentially unwanted outbound TCP connections to be made.

It is bad usability (and perhaps even a breach of trust) to take actions on behalf of the end-user that the end-user cannot reasonably expect.

With that said: if done in a 100% opt-in fashion this change seems fine conceptually.

Technical feedback:

• Please avoid introducing the boost::process dependency.
• Needs a test: Could use a mocked tor command.

@luke-jr #15382 in its current incarnation uses boost::process as well, and includes some simple detection code (it just checks if the version is >=1.64). It also has a functional test with a mock executable Python script, so that might be useful here too. @practicalswift I agree we shouldn't be launching arbitrary binaries named "tor" without the user opting into that. I'm not sure how this PR changes existing behavior. For modern versions of Tor we automatically create a hidden service if the user is running Tor: "if Tor is running (and proper authentication has been configured), Bitcoin Core automatically creates a hidden service to listen on", but that's quite different from starting Tor.

@Sjors Yes, that is very different: if Tor is already running and proper authentication has been configured then the user has already opted in to using Tor.

@practicalswift

This should be opt-in and not enabled by default, right?

Starting tor without the end-user asking for it explicitly is highly surprising. Also it could cause potentially unwanted outbound TCP connections to be made.

We already make outbound TCP connections by default. Note that this does not operate Tor as an exit node, nor does it even use it for outbound connections - it is exclusively for an inbound hidden service only.

The end goal, is to display the hidden service address in a QR code for easy pairing with mobile wallets.

Please avoid introducing the boost::process dependency.

Not practical. We're going to need it either way from the sound of it.

configure now checks for boost::process availability, and -onion is not configured for private Tor instances (which don't offer the SOCKS service).

Could add FascistFirewall 1 to the config to make sure only port 80 and 443 are used?

@practicalswift I don't see the need - we already connect out on 8333...

@luke-jr Sorry for being unclear. I was referring to the Tor network traffic :-)

@practicalswift What does it matter?

Note that this does not operate Tor as an exit node, nor does it even use it for outbound connections - it is exclusively for an inbound hidden service only.

That's still detectable for network observers afaik. Let's just add a tor= setting.

It also seems unsafe to call a random executable in the users path called tor, so we could ask for a full path, but that might be too annoying UX. The tor= setting could help in that regard too.

@luke-jr I don't hold any strong opinion but my reasoning was the following: if we're adding a default configuration then we might as well doing it using port settings which maximise the likelihood of it working out of the box.

Rebased

<!--cf906140f33d8803c4a75a2196329ecb-->

🐙 This pull request conflicts with the target branch and needs rebase.

_{Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".}

Closing due to lack of agreement/reviews...