please don't kill WarnUnsafeSocks option

The message

The WarnUnsafeSocks option is deprecated, and will most likely be removed in a future version of Tor. Changing this option makes it easier for you to accidentally lose your anonymity by leaking DNS information (If you think this is a mistake, please let us know!)

now appears when starting tor since a version upgrade.

I am a expert user of Tor and have several script that issue torsocks dig +tcp commands performing forward and reverse DNS queries. Have set WarnUnsafeSocks to 0 to eliminate the spamming of my logs with warnings about explicit IP addresses passing through SOCKS.

The option is useful and should be retained.

changed milestone to %Tor: unspecified

added anti-deprecation component::core tor/tor milestone::Tor: unspecified needs-design priority::medium regression? severity::normal status::new tor-client type::defect version::tor 0.2.9.2-alpha labels

Trac:
Component: - Select a component to Core Tor/Tor
Version: N/A to Tor: unspecified

This is related to #19820 (moved) where the option was deprecated and #22060 (moved) where the option was removed.

Trac:
Version: Tor: unspecified to Tor: 0.2.9.2-alpha

Looking at the code (see buffers.c:1325) the warning is only given if the SafeSocks option is enabled. According to the manual SafeSocks is disabled by default.

So unless the default is changed there should be no warnings.

Ok, thank for for explaining!

Replying to starlight:

Ok, thank for for explaining! Does removing the WarnUnsafeSocks option from your configuration fix the issue?

Trac:
Status: new to needs_information

Yes, works ok. Set WarnUnsafeSocks=1 via control channel in the client daemon, verified that it took and then ran the script that analyzes an IP address via several forward and reverse DNS queries using torsocks dig +tcp commands. No complaints in the log. Version 0.2.9.11.

Thank you.

Trac:
Resolution: N/A to not a bug
Status: needs_information to closed

Not so fast! It's been awhile since this was a bother and I forgot that the log spamming occurs on an control channel event monitoring stream. With WarnUnsafeSocks=1 this log is still flooding with pointless messages when DNS queries are purposefully sent over a Tor connection. I have restored WarnUnsafeSocks=0 and my position remains that the setting is useful at least up to and including 0.2.9.x. I have not tested 0.3.0.x versions.

Replying to starlight:

Not so fast! It's been awhile since this was a bother and I forgot that the log spamming occurs on an control channel event monitoring stream. With WarnUnsafeSocks=1 this log is still flooding with pointless messages when DNS queries are purposefully sent over a Tor connection. I have restored WarnUnsafeSocks=0 and my position remains that the setting is useful at least up to and including 0.2.9.x. I have not tested 0.3.0.x versions. The code referred to in comment:3 sends out the controller message no matter the value of SafeSocks. I'm assuming this is to prevent configuration options from hiding events from the controllers.

Because this is now about the controller message it sounds like a duplicate of #22461 (moved). Can you check if your issue is a duplicate of #22461 (moved)? If it's not a duplicate, can you give some more information about your setup in order to reproduce the issue?

Trac:
Status: closed to reopened
Resolution: not a bug to N/A

Seems to me the issues are related, but a difference exists. Bug #22461 (moved) talks about making SOCKS5 requests of a naked IP address. In this case I sometimes direct DNS requests to Google DNS.

Here DNS payloads are traversing SOCKS which contain naked IP addresses, and apparently it does not matter if the DNS server is specified via IP address or DNS name.

For example

$ torsocks dig +tcp +short @google-public-dns-a.google.com google-public-dns-b.google.com
8.8.4.4

still produces

650 STATUS_CLIENT WARN DANGEROUS_SOCKS PROTOCOL=SOCKS5 ADDRESS=8.8.8.8:53

If one submits the request in more usual fashion

$ torsocks dig +tcp +short @8.8.8.8 -x 8.8.4.4
google-public-dns-b.google.com.

the result is one 650 warning, not two.

with WarnUnsafeSocks=0 no 650 warnings appear.

#22461 (moved) was merged to master so I've tried to reproduce your issue on the master branch and I'm able to reproduce it. I did find however that issue in #22461 (moved) was also reproducible so let's see what happens when it is actually fixed properly.

Trac:
Status: reopened to new

Missing milestone.

Trac:
Milestone: N/A to Tor: unspecified

Trac:
Keywords: N/A deleted, anti-deprecation tor-client needs-design added

Trac:
Keywords: anti-deprecation tor-client needs-design deleted, anti-deprecation tor-client needs-design regression? added

The motivation for removing the option (to prevent people from harming themselves inadvertently) is evident and sensible. For me it would work if a prefix to the socks isolation username or password acted as a flag to suppress the warning. Perhaps "UNSAFE" or similar blatant indication. The purpose of the script where this happens is issuing arbitrary DNS queries anonymously--no chance I will accidently request my own addresses unintentionally.

Or, don't worry about it. I prefer logs clear of distracting noise (so I don't miss important messages) and have demoted several daemon messages to info or debug level in my builds. I can hack this one as well. But spam is spam and it invariable harms the signal-to-noise ratio on any channel.

moved to tpo/core/tor#22572 (closed)