Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T16:08:55Zhttps://gitlab.torproject.org/legacy/trac/-/issues/801Torify+dsocks: A listener connection returned a socket with a mismatched family2020-06-13T16:08:55ZTracTorify+dsocks: A listener connection returned a socket with a mismatched familyWhen i try to torify something trought dsocks-torify.sh it doesn't works.
Example:
dsocks-torify.sh nmap -P0 -v -n 1.2.3.4 -p21 -sV
Starting Nmap 4.50 ( http://insecure.org ) at 2008-08-16 13:45 CEST
Initiating Connect Scan at 13:45
Sc...When i try to torify something trought dsocks-torify.sh it doesn't works.
Example:
dsocks-torify.sh nmap -P0 -v -n 1.2.3.4 -p21 -sV
Starting Nmap 4.50 ( http://insecure.org ) at 2008-08-16 13:45 CEST
Initiating Connect Scan at 13:45
Scanning 87.29.167.157 [1 port]
nmap: (dsocks) couldn't connect to proxy at 127.0.0.1:9050
Discovered open port 21/tcp on 87.29.167.157
Completed Connect Scan at 13:45, 0.14s elapsed (1 total ports)
Host 87.29.167.157 appears to be up ... good.
Interesting ports on 87.29.167.157:
PORT STATE SERVICE
21/tcp open ftp
Nmap done: 1 IP address (1 host up) scanned in 0.204 seconds
this is the entry in the Tor debub log
[info] connection_handle_listener_read(): Bug: A listener connection returned a socket with a mismatched family. Socks listener for addr_family 2 gave us a socket with address family 0. Dropping.
i've the last version of dsocks aviable from darwinports.
Thanks to all!
bye
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: m4rco-David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/3711Application support for optimistic data: Torsocks2020-06-13T16:08:56ZNick MathewsonApplication support for optimistic data: TorsocksNow that Tor (as of 0.2.3.x) supports optimistic data, we should try to get torsocks to support it.
This won't be totally trivial, since we'll need to tell the application "yes, it connected" early, and then give an error if the connect...Now that Tor (as of 0.2.3.x) supports optimistic data, we should try to get torsocks to support it.
This won't be totally trivial, since we'll need to tell the application "yes, it connected" early, and then give an error if the connection actually happens. (Perhaps we can get away with doing an early shutdown() on the connection so that reads and writes fail, but the fd lingers. If not, we'll have to intercept read, write, pread, pwrite, writev, select, etc, so that we can give an error if needed.)
There was some discussion of this in the comments of #1849.Matthew FinkelMatthew Finkelhttps://gitlab.torproject.org/legacy/trac/-/issues/6155Import torsocks from google code to torproject.org trac2020-06-13T16:08:57ZproperImport torsocks from google code to torproject.org tracReasons:
* You can not post anonymously to the google code tracker.
* You can not have an anonymous google account, since it requires verification.
* Google code is not accessible from some countries.
* It's Tor standard software, in...Reasons:
* You can not post anonymously to the google code tracker.
* You can not have an anonymous google account, since it requires verification.
* Google code is not accessible from some countries.
* It's Tor standard software, in the torproject.org repository, and you can't really keep track of it there.Robert HoganRobert Hoganhttps://gitlab.torproject.org/legacy/trac/-/issues/6228NSS module for .onion DNS name resolution2020-06-13T16:08:57ZTracNSS module for .onion DNS name resolutionFrom a usability point of view it'd be great to always have .onion addresses resolved via Tor - system wide, by default. It'd make .onion addresses a first-class citizen in the overall web browsing experience.
The idea is to provide a l...From a usability point of view it'd be great to always have .onion addresses resolved via Tor - system wide, by default. It'd make .onion addresses a first-class citizen in the overall web browsing experience.
The idea is to provide a libnss-tor module to by default always resolve .onion addresses via Tor, with no need for 'torify', proxy configurations within an application etc. Similar to what libnss-mdns does for .local addresses for instance.
Thanks to [this](https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy) I came up with the following setup to achieve the same thing:
* torrc with 'AutomapHostsOnResolve 1', 'DNSPort 53535' and 'TransPort 9040'
* dnsmasq with a 'server=/onion/127.0.0.1!#53535'
* iptables -t nat -A OUTPUT -p tcp -d 127.192.0.0/10 -j REDIRECT --to-ports 9040
* 'nameserver 127.0.0.1' in /etc/resolv.conf
However having a libnss-tor for that would remove the iptables/dnsmasq part, which should make it way more convinient for most people. It'd also make the mapaddress option in the torrc obsolete, I think.
Further things to consider:
* Security implications?
* Does something like libnss exist for other operating systems, too?
**Trac**:
**Username**: tuxhttps://gitlab.torproject.org/legacy/trac/-/issues/6542curl 7.27.0 doesn't work with torsocks2020-06-13T16:08:58Zcypherpunkscurl 7.27.0 doesn't work with torsocksAfter upgrading curl to version 7.27.0, various programs that depend on libcurl (including curl itself) no longer work with torsocks.
All requests are replied to with the "501 Tor is not an HTTP proxy" message. Curiously, the first two ...After upgrading curl to version 7.27.0, various programs that depend on libcurl (including curl itself) no longer work with torsocks.
All requests are replied to with the "501 Tor is not an HTTP proxy" message. Curiously, the first two bytes of the response are 0x05 0x00 as you would expect from a valid SOCKS5 reply.
Perhaps there's some poor buffer management lurking around.
Thanks.
Software versions:
Linux 3.4.7-1-ARCH i686
curl 7.27.0
torsocks 1.2
tor 0.2.2.37David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/7564[PATCH] Use libdir instead of prefix in torsocks wrapper2020-06-13T16:08:59ZTrac[PATCH] Use libdir instead of prefix in torsocks wrapperUse the autotools configure standard for assigning the library directory.
**Trac**:
**Username**: robinsonUse the autotools configure standard for assigning the library directory.
**Trac**:
**Username**: robinsonhttps://gitlab.torproject.org/legacy/trac/-/issues/8006Unnecessary test in torsocks script2020-06-13T16:08:59ZTracUnnecessary test in torsocks scriptTorsocks suggests running with no arguments to start a shell, however the launcher script errors when no arguments are passed. Attached patch fixes this.
**Trac**:
**Username**: dmaTorsocks suggests running with no arguments to start a shell, however the launcher script errors when no arguments are passed. Attached patch fixes this.
**Trac**:
**Username**: dmahttps://gitlab.torproject.org/legacy/trac/-/issues/8038Allow torsocks to interact with TBB in a useful way2020-06-13T16:09:00ZMatthew FinkelAllow torsocks to interact with TBB in a useful wayTBB will select a random SOCKS port, torsocks should provide a way to find/be given this port number. Asking users to retrieve it from Data/Tor/port.conf and modify torsocks.conf is nonobvious.TBB will select a random SOCKS port, torsocks should provide a way to find/be given this port number. Asking users to retrieve it from Data/Tor/port.conf and modify torsocks.conf is nonobvious.https://gitlab.torproject.org/legacy/trac/-/issues/8043various torsocks/ttdnsd errors and discrepancies2020-06-13T16:09:00ZTracvarious torsocks/ttdnsd errors and discrepanciesFor the past two weeks I have been trying to integrate ttdnsd/torsocks combo into my system, allowing for proper DNS resolution to take place over Tor - all this was prompted by my report on bug #7797. Unfortunately, I've hit a brick wal...For the past two weeks I have been trying to integrate ttdnsd/torsocks combo into my system, allowing for proper DNS resolution to take place over Tor - all this was prompted by my report on bug #7797. Unfortunately, I've hit a brick wall.
In a nutshell, I have found a few discrepancies/errors in both torsocks and ttdnsd and I also have a problem trying to force torsocks to talk to tor.
Since in the "Component" section on this report form there is no place to select ttdnsd, I am doing this report for torsocks, as well as ttdnsd.
1. Torsocks config file environment variable: ttdnsd expects that to be defined in TSOCKS_CONF_FILE, while torsocks also have 2 different definitions of it: TORSOCKS_CONFFILE (torsocks.8) and TORSOCKS_CONF_FILE (the binary .so file). The latter, when specified, works.
Also, that environment variable is only honoured BEFORE chroot (so the full path to this file MUST be specified) - something not mentioned in either of torsocks or ttdnsd man pages.
2. Even though I am using all 3 environment variables, pointing to the right torsocks.conf file, I still can't make it work. Here is my config:
torsocks.conf
=============
local = 127.0.0.0/255.0.0.0
local = 10.0.0.0/255.0.0.0
server = 127.0.0.1
server_port = 19050
ttdnsd.conf
===========
8.8.8.8
torrc (relevant parts only are included)
========================================
SocksPort 19050
SocksListenAddress 127.0.0.1:19050
DNSPort 53
DNSListenAddress 127.0.0.3:53
SocksPolicy accept 127.0.0.1:* # localhost
SocksPolicy accept 127.0.0.2:* # localhost
SocksPolicy accept 127.0.0.3:* # localhost
SocksPolicy accept 10.0.0.0/8:*
SocksPolicy reject *:*
My tor proxy service is running on 127.0.0.1:19050. TTDNSD is running on 127.0.0.2:53, while tor's own DNS is running on 127.0.0.3:53.
When not using TORSOCKS_DEBUG during ttdnsd start, after the initial setup I get the following message when a DNS request is sent to ttdnsd from the command line (using dig):
07:37:32 libtorsocks(2507): Call to connect received on completed request 4
07:37:32 libtorsocks(2507): sendto: Connection is a UDP or ICMP stream, may be a DNS request or other form of leak: rejecting.
When TORSOCKS_DEBUG=1 is used, I get this:
libtorsocks: Got connection request
libtorsocks: Intercepted call to getpeername
libtorsocks: Intercepted call to poll
libtorsocks: Intercepted call to poll
libtorsocks: Got connection request
libtorsocks: Call to connect received on completed request 4
libtorsocks: Got sendto request
libtorsocks: sendto: Connection is a UDP or ICMP stream, may be a DNS request or other form of leak: rejecting.
libtorsocks: Got sendto request
libtorsocks: sendto: Connection is a UDP or ICMP stream, may be a DNS request or other form of leak: rejecting.
[...ad nauseum...]
When I increase the debug level (TORSOCKS_DEBUG=255) I get a different message, though the effect is the same:
07:40:43 libtorsocks(2611): No requests waiting, calling real close
07:40:43 libtorsocks(2611): No requests waiting, calling real close
07:41:01 libtorsocks(2611): Got connection request
07:41:01 libtorsocks(2611): sin_family: 2
07:41:01 libtorsocks(2611): sockopt: 1
07:41:01 libtorsocks(2611): checking if address: 8.8.8.8 is local
07:41:01 libtorsocks(2611): localnet addr: 255.255.0.0
07:41:01 libtorsocks(2611): localip addr: 192.168.0.0
[...]
07:41:01 libtorsocks(2611): address: 8.8.8.8 is not local
07:41:01 libtorsocks(2611): Intercepted call to getpeername
07:41:01 libtorsocks(2611): Call to getpeername for fd 4
07:41:01 libtorsocks(2611): Got connection request for socket 4 to 8.8.8.8
07:41:01 libtorsocks(2611): Picking appropriate server for 8.8.8.8
07:41:01 libtorsocks(2611): Picked server 127.0.0.1 for connection
07:41:01 libtorsocks(2611): checking if address: 127.0.0.1 is local
[...]
07:41:01 libtorsocks(2611): address: 127.0.0.0 is local
07:41:01 libtorsocks(2611): Beginning handle loop for socket 4
07:41:01 libtorsocks(2611): In request handle loop for socket 4, current state of request is 0
07:41:01 libtorsocks(2611): Connecting to 127.0.0.1 port 19050
07:41:01 libtorsocks(2611): Connect returned -1, errno is 115
07:41:01 libtorsocks(2611): Error 2 attempting to connect to SOCKS server (No such file or directory)
07:41:01 libtorsocks(2611): Handle loop completed for socket 4 in state 14, returning 2
connect status: No such file or directory
We've loaded 8.8.8.8 as a nameserver.
1 nameservers loaded
tsocks_conf: torsocks.conf
log init...
log file opened: ttdnsd.log
log file opened as fd: 4
duping fds... check ttdnsd.log from here on out...
dup2 says: 1
dup2 says: 2
closing original fd: 4...
starting server...
watching 1 file descriptors
1 file descriptors became ready
received request of 37 bytes, id = 4927
adding new request (id=4927)
new request added at pos: 436
using request slot 436
updating id: 16147
selecting peer
peer selected: -1
connecting to 8.8.8.8 on port 53
watching 2 file descriptors
1 file descriptors became ready
peer 8.8.8.8 in bad state 0
watching 2 file descriptors
1 file descriptors became ready
peer 8.8.8.8 in bad state 0
watching 2 file descriptors
[...ad nauseum...]
I have absolutely no idea what the above errors mean exactly!
The connection attempts were made from 127.0.0.1:XXXXX (dig) to 127.0.0.2:53 (ttdnsd) using UDP, and then I could see from /proc/net/nf_conntrack that a separate connection was indeed made (status is ASSURED) to the tor proxy (127.0.0.1:19050) from torsocks (127.0.0.2:XXXXX) using TCP.
**Trac**:
**Username**: mr-4https://gitlab.torproject.org/legacy/trac/-/issues/8052merge torify trac component with torsocks trac component2020-06-13T16:09:01Zpropermerge torify trac component with torsocks trac componentWhat is the torify trac component good for nowadays? Merge it with the torsocks trac component?
[[TicketQuery(component=Torify,order=status,format=table,col=id|summary|status|priority|keywords|owner|)]]What is the torify trac component good for nowadays? Merge it with the torsocks trac component?
[[TicketQuery(component=Torify,order=status,format=table,col=id|summary|status|priority|keywords|owner|)]]https://gitlab.torproject.org/legacy/trac/-/issues/8053add stream isolation support to torsocks2020-06-13T16:09:01Zproperadd stream isolation support to torsocksThere is [uwt](https://trac.torproject.org/projects/tor/wiki/doc/torsocks#uwt-modifiedusewithtortoimproveTorstreamisolation), but it's a hack (creates a temporary torsocks configuration file very time torsocks is started), has bugs and i...There is [uwt](https://trac.torproject.org/projects/tor/wiki/doc/torsocks#uwt-modifiedusewithtortoimproveTorstreamisolation), but it's a hack (creates a temporary torsocks configuration file very time torsocks is started), has bugs and is not in the upstream torsocks package.
Please add the ability to set proxy type, IP address and port by command line. The interface could look like this:
```
torsocks -t 5 -i 127.0.0.1 -p 9050 /usr/bin/wget -c https://check.torproject.org
```
```
sudo torsocks -t 5 -i 127.0.0.1 -p 9052 /usr/bin/apt-get --yes dist-upgrade
```
The user could open multiple SocksPorts (9050, 9052, 9053, etc.) and use torsocks while separating the streams.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/8063torsocks on doesn't work.2020-06-13T16:09:02ZTractorsocks on doesn't work.Hi,
The "torsocks on" subcommand exports the LD_PRELOAD (Linux) or DYLD_INSERT_LIBRARIES (OSX), but as the torsocks script finishes in bash the exports are lost, as the control returns to the parent process (the bash shell) of the torso...Hi,
The "torsocks on" subcommand exports the LD_PRELOAD (Linux) or DYLD_INSERT_LIBRARIES (OSX), but as the torsocks script finishes in bash the exports are lost, as the control returns to the parent process (the bash shell) of the torsocks script.
The easiest fix is to start a new shell from the "torsocks on" subcommand execution.
Oscar
**Trac**:
**Username**: okoeroohttps://gitlab.torproject.org/legacy/trac/-/issues/8066usewithtor + irssi + ssl = "Socks version 22 not recognized"2020-06-13T16:09:02ZRoger Dingledineusewithtor + irssi + ssl = "Socks version 22 not recognized"Set up your ~/.irssi/config with
```
servers = (
{
address = "irc.oftc.net";
chatnet = "oftc";
#port = "6667";
port = "6697";
use_ssl = "yes";
# ssl_cert = "~/.irssi/certs/[NICK].pem";
# ssl_verify = "yes";
...Set up your ~/.irssi/config with
```
servers = (
{
address = "irc.oftc.net";
chatnet = "oftc";
#port = "6667";
port = "6697";
use_ssl = "yes";
# ssl_cert = "~/.irssi/certs/[NICK].pem";
# ssl_verify = "yes";
# ssl_cafile = "~/.irssi/certs/CAs.pem";
autoconnect = "yes";
}
);
```
and then run
```
usewithtor irssi
```
Your Tor client will log something like
```
Jan 27 17:43:52.000 [warn] Socks version 22 not recognized. (Tor is not an http proxy.)
Jan 27 17:43:52.000 [warn] Fetching socks handshake failed. Closing.
```
and your irssi will complain with something like
```
18:06 -!- Irssi: Looking up irc.oftc.net
18:06 -!- Irssi: Connecting to irc.oftc.net [140.211.166.64] port 6697
18:06 -!- Irssi: warning SSL handshake failed: Connection reset by peer
18:06 -!- Irssi: Connection lost to irc.oftc.net
```
What's happening behind the scenes is that your irssi is attempting a connect, getting an einprogress (presumably since it's non-blocking), sending the ssl handshake right then, and then later torsocks tries to inject the socks handshake. Oops.
```
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(4, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
getsockopt(4, SOL_SOCKET, SO_TYPE, [1], [4]) = 0
getpeername(4, 0x7fff04186010, [16]) = -1 ENOTCONN (Transport endpoint is not connected)
connect(4, {sa_family=AF_INET, sin_port=htons(9050), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
fstat(4, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
fcntl(4, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
...
write(4, "\26\3\1\1;\1\0\0017\3\3Q\5\253\315\302\4\246F_\255\232\205\206h\24\345\351\310e'\r"..., 320) = 320
read(4, 0x19a9770, 7) = -1 EAGAIN (Resource temporarily unavailable)
...
sendto(4, "\4\1\32)\0\0\0\1arma\0irc.oftc.net\0", 26, 0, NULL, 0) = 26
recvfrom(4, "", 8, 0, NULL, NULL) = 0
...
close(4) = 0
```https://gitlab.torproject.org/legacy/trac/-/issues/8067Three harmless compiler warnings in 1.2 and 1.32020-06-13T16:09:03ZRoger DingledineThree harmless compiler warnings in 1.2 and 1.3```
torsocks.c: In function ‘torsocks_select_guts’:
torsocks.c:428:9: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
torsocks.c: In function ‘torsocks_poll_guts’:
torsocks.c:613:9: warning: variable ‘rc’ set but not ...```
torsocks.c: In function ‘torsocks_select_guts’:
torsocks.c:428:9: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
torsocks.c: In function ‘torsocks_poll_guts’:
torsocks.c:613:9: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
...
test_torsocks.c:144:14: warning: ‘txtquery’ defined but not used [-Wunused-function]
```
(on debian wheezy)Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/legacy/trac/-/issues/8068Missing symbol namespacing2020-06-13T16:09:03ZDavid Gouletdgoulet@torproject.orgMissing symbol namespacingBy doing this command we can see a bunch of symbols that torsocks should *not* try to overload:
```
$ nm .libs/libtorsocks.so | grep " T "
```
Here is the list that I think should be hidden:
```
0000000000007190 T count_netmask_bits
0...By doing this command we can see a bunch of symbols that torsocks should *not* try to overload:
```
$ nm .libs/libtorsocks.so | grep " T "
```
Here is the list that I think should be hidden:
```
0000000000007190 T count_netmask_bits
0000000000009fa0 T find_socks_request
0000000000009320 T get_next_dead_address
00000000000095d0 T get_pool_entry
0000000000007050 T get_uint16
0000000000007060 T get_uint32
0000000000006a70 T getipnodebyname
0000000000009ff0 T handle_request
00000000000090e0 T init_pool
0000000000009300 T is_dead_address
0000000000007470 T is_local
0000000000009f30 T kill_socks_request
0000000000009e70 T new_socks_request
0000000000009950 T our_getaddrinfo
00000000000096a0 T our_gethostbyaddr
0000000000009860 T our_gethostbyname
0000000000009a40 T our_getipnodebyname
00000000000075d0 T pick_server
0000000000007d90 T read_config
0000000000007090 T resolve_ip
0000000000009350 T search_pool_for_name
0000000000007130 T set_log_options
0000000000007070 T set_uint16
0000000000007080 T set_uint32
00000000000071c0 T show_msg
00000000000093c0 T store_pool_entry
0000000000007700 T strsplit
```
These symbols should at least have a torsocks_* prefix or else they might clash with existing symbols linked to the binary called with torsocks altering its behavior which is real *BAD*.
The quickest way of fixing that would be to add the GCC hidden attribute to each function call or else try to make them static in the code base.
I've notice that with the "read_config" symbol that was overloaded in my software with the current git head (519d3be56348c3d965c286a7c04adce3dd556411).
Thanks!
DavidJacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/legacy/trac/-/issues/8070Memory leaks on error in dead_pool.c2020-06-13T16:09:04ZDavid Gouletdgoulet@torproject.orgMemory leaks on error in dead_pool.cIn parse_socks5_resolve_ptr_response() (dead_pool.c +325), the **result_hostname is allocated then passed to recv(). On error (r < 0) or with an orderly shutdown (r = 0) the memory is not freed causing the memory leak.
Here is a small p...In parse_socks5_resolve_ptr_response() (dead_pool.c +325), the **result_hostname is allocated then passed to recv(). On error (r < 0) or with an orderly shutdown (r = 0) the memory is not freed causing the memory leak.
Here is a small patch fixing the leak.Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/legacy/trac/-/issues/8137add option to allow connections to local addresses2020-06-13T16:09:06Zproperadd option to allow connections to local addresses> libtorsocks(11014): connect: Connection is to a local address (192.168.0.10), may be a TCP DNS request to a local DNS server so have to reject to be safe. Please report a bug to http://code.google.com/p/torsocks/issues/entry if this is...> libtorsocks(11014): connect: Connection is to a local address (192.168.0.10), may be a TCP DNS request to a local DNS server so have to reject to be safe. Please report a bug to http://code.google.com/p/torsocks/issues/entry if this is preventing a program from working properly with torsocks.
Please add an option to allow connections to local addresses. Tor doesn't always run on 127.0.0.1, sometimes it's run on a machine on local LAN. This is also the case for Whonix, which is a two machine approach, where Tor runs by design on another machine on local LAN.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/8220add TORSOCKS_CONF_FILE to debug output2020-06-13T16:09:06Zproperadd TORSOCKS_CONF_FILE to debug outputWhen
```
export TORSOCKS_DEBUG=1
```
is set, please add $TORSOCKS_CONF_FILE to the debug output.When
```
export TORSOCKS_DEBUG=1
```
is set, please add $TORSOCKS_CONF_FILE to the debug output.Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/legacy/trac/-/issues/8221add configuration to debug output2020-06-13T16:09:07Zproperadd configuration to debug outputWhen
```
export TORSOCKS_DEBUG=1
```
is set, please add the torsocks configuration to the debug output. (Stuff from /etc/torsocks.conf.)When
```
export TORSOCKS_DEBUG=1
```
is set, please add the torsocks configuration to the debug output. (Stuff from /etc/torsocks.conf.)Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/legacy/trac/-/issues/8272torsocks.c warning says to file bugs at code.google.com2020-06-13T16:09:07ZRoger Dingledinetorsocks.c warning says to file bugs at code.google.comhttps://gitweb.torproject.org/torsocks.git/blob/HEAD:/src/torsocks.c#l280 says
```
show_msg(MSGERR, "connect: Connection is to a local address (%s), may be a "
"TCP DNS request to a local DNS server so have...https://gitweb.torproject.org/torsocks.git/blob/HEAD:/src/torsocks.c#l280 says
```
show_msg(MSGERR, "connect: Connection is to a local address (%s), may be a "
"TCP DNS request to a local DNS server so have to reject to be safe. "
"Please report a bug to http://code.google.com/p/torsocks/issues/entry if "
"this is preventing a program from working properly with torsocks.\n", buf);
```
This is the wrong place to file torsocks bugs now, right?Jacob AppelbaumJacob Appelbaum