Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T16:09:39Zhttps://gitlab.torproject.org/legacy/trac/-/issues/17479Allow port 655352020-06-13T16:09:39ZTracAllow port 65535Port 65535 is a valid port among the tor code base. In fact, in_port_t
type will guarantee a valid port number. The only special value is "0",
so drop the 65535 check completely.
**Trac**:
**Username**: junglefowlPort 65535 is a valid port among the tor code base. In fact, in_port_t
type will guarantee a valid port number. The only special value is "0",
so drop the 65535 check completely.
**Trac**:
**Username**: junglefowlDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/17478Fix typos in comments2020-06-13T16:09:39ZTracFix typos in commentsThere are some typos in comments.
**Trac**:
**Username**: junglefowlThere are some typos in comments.
**Trac**:
**Username**: junglefowlDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/17475Overflow when parsing config lines with many arguments2020-06-13T16:09:38ZTracOverflow when parsing config lines with many argumentsIt is possible to overflow tokens with a configuration that contains many
arguments in one line.
At first, the upper limit is specified as sizeof(tokens), which is
wrong. It has to be DEFAULT_MAX_CONF_TOKEN or sizeof(tokens) /
sizeof(to...It is possible to overflow tokens with a configuration that contains many
arguments in one line.
At first, the upper limit is specified as sizeof(tokens), which is
wrong. It has to be DEFAULT_MAX_CONF_TOKEN or sizeof(tokens) /
sizeof(tokens[0]). The former is shorter, therefor I took that one.
The next issue is in utils_tokenize_ignore_comments, which verifies that
enough space is available only with the ' ' separator. Later in the code,
'\t' is also allowed as a separator, which means that more arguments could
show up than previously taken into account during size checks.
This is an unlikely case, so the check will be done while parsing. When
the limit is reached, previously allocated memory is released again and
error value is returned.
**Trac**:
**Username**: junglefowlDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/17340Add support for specifying Tor address and port from the command line2020-06-13T16:09:38ZAlexander Færøyahf@torproject.orgAdd support for specifying Tor address and port from the command lineThis set of patches first refactors the Torsocks code to allow the user to specify the address and port of the Tor instance they wish to connect to and thereafter adds a `--address` (`-a`) and `--port` (`-P` - since `-p` was already used...This set of patches first refactors the Torsocks code to allow the user to specify the address and port of the Tor instance they wish to connect to and thereafter adds a `--address` (`-a`) and `--port` (`-P` - since `-p` was already used as shorthand for `--pass`) option to the `torsocks` script.
The `0001` patch is minor fix that was found whilst reading the source code before working on the feature.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16991I think I've figured out why torsocks-ci-linux is failing on Jenkins!2020-06-13T16:09:37ZNick MathewsonI think I've figured out why torsocks-ci-linux is failing on Jenkins!So, the tests seem to assume that there is a tor process running that can receive their queries, and that it's on the internet, and that while on the internet it can connect to the Tor network.
Not crazy I guess!
But FWICT the Jenkins...So, the tests seem to assume that there is a tor process running that can receive their queries, and that it's on the internet, and that while on the internet it can connect to the Tor network.
Not crazy I guess!
But FWICT the Jenkins builder hasn't launched a Tor process, or has shut off access to the network. I guess that's why it's failing in test_dns.c
So, the question:
Q1. Does torsocks really require for its tests that there exist a Tor process on port 9050 with access to the internet?
If the answer to Q1 is no, there is a bug in torsocks.
If the answer to Q1 is yes, there are three possible solutions I see:
S1. Change torsocks so that no tests require a running Tor with access to the internet.
S2. Change the Jenkins configuration so that it launches a tor client process for the torsocks test to use.
S3. Divide the torsocks tests into the ones that need a Tor connected to the network, and the ones that do not. Only run the ones that do not when we're running under Jenkins.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16934youtube-dl (recent), torsocks 2.1.0 and TBB5+ failure2020-06-13T16:09:37ZTracyoutube-dl (recent), torsocks 2.1.0 and TBB5+ failureERROR torsocks[29369]: [socks5] Resolve destination buffer too small (in socks5_recv_resolve_reply() at socks5.c:690)
ERROR: Unable to download webpage: <urlopen error [Errno -4] Non-recoverable failure in name resolution> (caused by URL...ERROR torsocks[29369]: [socks5] Resolve destination buffer too small (in socks5_recv_resolve_reply() at socks5.c:690)
ERROR: Unable to download webpage: <urlopen error [Errno -4] Non-recoverable failure in name resolution> (caused by URLError(gaierror(-4, 'Non-recoverable failure in name resolution'),))
The error changes over time. But it is mostly in this range. With a fresh restart the problem goes away, but it is back after some time blocking all requests.
Stopping any TBB5 running and starting TBB4.5.3 makes everything go smooth again.
Besides TBB, nothing changes in the configuration.
**Trac**:
**Username**: sponvillehttps://gitlab.torproject.org/legacy/trac/-/issues/16765torsocks should allow UDP connections to localhost when AllowOutboundLocalhos...2020-06-13T16:09:36Zsajolidatorsocks should allow UDP connections to localhost when AllowOutboundLocalhost is setAs described on https://labs.riseup.net/code/issues/8054#note-17, torsocks 2.1 seems to only allow TCP connections to localhost when AllowOutboundLocalhost is set in torsocks.conf. This option should be extended to allow UDP connections ...As described on https://labs.riseup.net/code/issues/8054#note-17, torsocks 2.1 seems to only allow TCP connections to localhost when AllowOutboundLocalhost is set in torsocks.conf. This option should be extended to allow UDP connections as well. Assigning to Yawning who seems to volunteer :)
This will be useful for Tails to allow contributors to run our script for verifying the well-behaving of our download mirrors. For this to work we need to be able to pass a DNS query through our local ttdnsd because such query cannot be handled directly by Tor.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16628tordns_enable option to disable dns resolving via tor2020-06-13T16:09:36ZTractordns_enable option to disable dns resolving via torI don't use tor. I just use torsocks to redirect tcp traffic to SOCKS5 proxy (ssh -D 9150 login@myserver). DNS resolving doesn't work in this way. Please add 'tordns_enable' option to manually disable dns resolving via socks proxy.
This...I don't use tor. I just use torsocks to redirect tcp traffic to SOCKS5 proxy (ssh -D 9150 login@myserver). DNS resolving doesn't work in this way. Please add 'tordns_enable' option to manually disable dns resolving via socks proxy.
This option is available in old "tsocks" app.
```
$ port info tsocks
tsocks @1.8.4_2 (net)
Variants: universal
Description: tsocks allows non SOCKS aware applications (e.g telnet, ssh, ftp etc) to use SOCKS without any
modification. It does this by intercepting the calls that applications make to establish network
connections and negotating them through a SOCKS server as necessary.
Homepage: http://ima.udg.edu/~rgarcia/tsocks/
Build Dependencies: autoconf, automake, libtool
Platforms: darwin
License: GPL-2+
Maintainers: nomaintainer@macports.org
$ cat /opt/local/etc/tsocks.conf | grep tordns
tordns_enable = false
```
**Trac**:
**Username**: s.lobanovDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16627torsocks 2.1 doesn't work with Oracle Java 8 (Mac OS X 10.9.5)2020-06-13T16:09:35ZTractorsocks 2.1 doesn't work with Oracle Java 8 (Mac OS X 10.9.5)torsocks 2.1 works OK with all applications except Oracle Java 8
For example:
```
$ torsocks telnet 184.105.238.114
Trying 184.105.238.114...
Connected to 184.105.238.114.
Escape character is '^]'.
This is the telnet autoresponder at v6...torsocks 2.1 works OK with all applications except Oracle Java 8
For example:
```
$ torsocks telnet 184.105.238.114
Trying 184.105.238.114...
Connected to 184.105.238.114.
Escape character is '^]'.
This is the telnet autoresponder at v6address.com.
You have connected over IPv4.
Your IP address is 82.X.Y.Z
Connection closed by foreign host.
```
With java:
```
$ torsocks java -jar utm_admin.jar
[Jul 21 11:35:33] WARNING torsocks[11015]: [syscall] Unsupported syscall number 180. Denying the call (in tsocks_syscall() at syscall.c:465)
[Jul 21 11:35:36] WARNING torsocks[11015]: [syscall] Unsupported syscall number 180. Denying the call (in tsocks_syscall() at syscall.c:465)
dyld: lazy symbol binding failed: Symbol not found: _JRSUIGetKey
Referenced from: /Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/libosxui.dylib
Expected in: flat namespace
dyld: Symbol not found: _JRSUIGetKey
Referenced from: /Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/libosxui.dylib
Expected in: flat namespace
Trace/BPT trap: 5
```
Versions:
```
$ torsocks --version
Torsocks 2.1.0
$ torsocks java -version
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
```
**Trac**:
**Username**: s.lobanovDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16435torsocks needlessly depends on perl for test suite2020-06-13T16:09:35Zcypherpunkstorsocks needlessly depends on perl for test suiteThe attached patch replaces the Perl tap driver by the shell-only automake tap driver, so that users need not have Perl installed in order to run the torsocks tests (nor do anything else with torsocks). This has the side effect of fixin...The attached patch replaces the Perl tap driver by the shell-only automake tap driver, so that users need not have Perl installed in order to run the torsocks tests (nor do anything else with torsocks). This has the side effect of fixing an issue with out-of-tree builds, and reducing local actions in tests/Makefile.am.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16434fix miscellaneous compiler warnings2020-06-13T16:09:34Zcypherpunksfix miscellaneous compiler warningsThe attached patch tweaks things to avoid miscellaneous compiler warnings, from GCC and from the Clang static analyzer:
- Avoid signed/unsigned comparison with judicious casts, justified by asserts.
- Use the same type for indices into ...The attached patch tweaks things to avoid miscellaneous compiler warnings, from GCC and from the Clang static analyzer:
- Avoid signed/unsigned comparison with judicious casts, justified by asserts.
- Use the same type for indices into an array as are used for the size of the array.
- Make sure variables are initialized even for error branches.
- Avoid possible null pointer dereference in case of test failure.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16433infinite recursion in torsocks log timestamps2020-06-13T16:09:34Zcypherpunksinfinite recursion in torsocks log timestampsIf libc calls `open` and `close` in order to deal with time zones for `localtime`, the torsocks interception of `close` may lead to infinite recursion: torsocks `close` tries to print a log message, which needs a timestamp, which it form...If libc calls `open` and `close` in order to deal with time zones for `localtime`, the torsocks interception of `close` may lead to infinite recursion: torsocks `close` tries to print a log message, which needs a timestamp, which it formats with `localtime`, which opens the tz database and calls `close` when done, which tries to print a log message, which needs a timestamp...
(NetBSD's libc is an example of such a libc. Note `gmtime` has the same property.)
The attached patch changes timestamps to be seconds since epoch minus leap seconds, i.e. a standard POSIX clock, in order to avoid this recursion.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16432patches for NetBSD2020-06-13T16:09:34Zcypherpunkspatches for NetBSDThe attached patches fix several issues on NetBSD:
* The cpp conditionals for mmap goo in syscall.c don't match and break on NetBSD.
* NetBSD <7 incorrectly declared the obsolete `gethostbyaddr` function to take `char *` rather than `vo...The attached patches fix several issues on NetBSD:
* The cpp conditionals for mmap goo in syscall.c don't match and break on NetBSD.
* NetBSD <7 incorrectly declared the obsolete `gethostbyaddr` function to take `char *` rather than `void *`.
* In NetBSD >=4, the ELF symbol for the `socket` routine in libc is named `__socket30`; the symbol named `socket` is a compatibility routine implementing older semantics in terms of the symbol `__socket30`.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16355[PATCH] Add usleep to data_impl functions2020-06-13T16:09:33Zcypherpunks[PATCH] Add usleep to data_impl functionsThe send_data_impl and recv_data_impl functions can enter an annoying
busy loop if a connection is laggy. Potentially if the connection
never establishes, this can continue for minutes, until the connection
times out, having at least one...The send_data_impl and recv_data_impl functions can enter an annoying
busy loop if a connection is laggy. Potentially if the connection
never establishes, this can continue for minutes, until the connection
times out, having at least one core running at 100% the entire time,
which is undesirable.
Adding a usleep(1000) is enough to make sure a torsocks'd program
doesn't 100% the CPU, and the user likely will not notice a 0.001
second delay.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16349Need to merge GigHub pull requests2020-06-13T16:09:33Zyurivict271Need to merge GigHub pull requestsPlease merge all GitHub pull requests: https://github.com/dgoulet/torsocks/pulls
And please close pull request section on GitHub if this isn't the proper location for requests to be filed.Please merge all GitHub pull requests: https://github.com/dgoulet/torsocks/pulls
And please close pull request section on GitHub if this isn't the proper location for requests to be filed.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16308Attempts to resolve local hostname using tor2020-06-13T16:09:32ZTracAttempts to resolve local hostname using torWhen using torsocks 2.1.0 built from tarball, torsocks attempts to resolve the local machine's hostname using tor.
To reproduce: clone a git repository using torsocks
Result: clone is successful, but produces an error in torsocks after...When using torsocks 2.1.0 built from tarball, torsocks attempts to resolve the local machine's hostname using tor.
To reproduce: clone a git repository using torsocks
Result: clone is successful, but produces an error in torsocks after an attempt to resolve the machine's hostname:42 using tor.
`ERROR torsocks[pid]: Unable to resolve. Status reply: 4 (in socks5_recv_resolve_reply() at socks5.c:666)`
**Trac**:
**Username**: leeroyDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16223Torsocks v2.1.0 fails to build on RHEL/CentOS 5.x2020-06-13T16:09:32ZTracTorsocks v2.1.0 fails to build on RHEL/CentOS 5.xThe newly-released torsocks v2.1.0 does not build in RHEL/CentOS v5.11 (all updates applied.)
This is the first error:
In file included from ref.h:23,
from connection.h:28,
from defaults.h:21,
...The newly-released torsocks v2.1.0 does not build in RHEL/CentOS v5.11 (all updates applied.)
This is the first error:
In file included from ref.h:23,
from connection.h:28,
from defaults.h:21,
from log.c:27:
compat.h:133:25: error: sys/eventfd.h: No such file or directory
make[2]: *** [log.lo] Error 1
This is due to the fact that eventfd.h really does not exist on this system. If I change the include from sys/eventfd.h to sys/syscall.h the compile finishes without error, but then the link fails:
../../src/lib/.libs/libtorsocks.so: undefined reference to `eventfd'
../../src/lib/.libs/libtorsocks.so: undefined reference to `inotify_init1'
../../src/lib/.libs/libtorsocks.so: undefined reference to `epoll_create1'
../../src/lib/.libs/libtorsocks.so: undefined reference to `epoll_pwait'
collect2: ld returned 1 exit status
No problems seen when building on a CentOS6 system, just on CentOS5.
The prior v2.0.0 does build on CentOS5 with the help of some function attribute trickery (prepending ATTR_HIDDEN to several function and data definitions).
**Trac**:
**Username**: tmpname0901David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16183torsocks upgrade broke OpenSSH connection sharing2020-06-13T16:09:31ZTractorsocks upgrade broke OpenSSH connection sharingAfter upgrading torsocks, I found that OpenSSH connection sharing did not work correctly anymore. It turned out that the master process (when running using torsocks) keeps file descriptors open which it received from the slave processes....After upgrading torsocks, I found that OpenSSH connection sharing did not work correctly anymore. It turned out that the master process (when running using torsocks) keeps file descriptors open which it received from the slave processes.
It turned out that the fd passing check introduced in commit eecc1152a9c8645 is responsible for the issue.
**Trac**:
**Username**: zeunerDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16006torsocks should support isolating on a per process basis.2020-06-13T16:09:31ZYawning Angeltorsocks should support isolating on a per process basis.#16004 + #14132 would be the better way to handle this since it allows doing this for more than torsocks, but as something that can happen in the mean time (or if the user doesn't want to use AF_UNIX based SOCKSSocket), there's no reason...#16004 + #14132 would be the better way to handle this since it allows doing this for more than torsocks, but as something that can happen in the mean time (or if the user doesn't want to use AF_UNIX based SOCKSSocket), there's no reason that torsocks can't do this automatically.
Rough idea:
```
IsolatePid 0|1
Automatically set the SOCKS5 username/password to a unique per-process value
that makes the connections to Tor use a different circuit from other existing
streams on a per-application basis. If set, the SOCKS5Username and
SOCKS5Password options must not be set. (Default: 0)
```
The implementation would stash the pid/`time(NULL)` on startup and use `pid:TIME` (both ASCII serialized) as the SOCKS5 username/password pair for all SOCKS connections.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/15584Linking libtorsocks with libtcmalloc results in SIGSEGV2020-06-13T16:09:30ZTracLinking libtorsocks with libtcmalloc results in SIGSEGVAny application that is linked against libtcmalloc gets SISEGV if it's being run with libtorsocks preloaded. However, it depends on preloading order.
If libtorsocks is preloaded first, app segfaults:
```
[~]$ LD_PRELOAD="/usr/lib64/tor...Any application that is linked against libtcmalloc gets SISEGV if it's being run with libtorsocks preloaded. However, it depends on preloading order.
If libtorsocks is preloaded first, app segfaults:
```
[~]$ LD_PRELOAD="/usr/lib64/torsocks/libtorsocks.so /usr/lib64/libtcmalloc_debug.so" uname -a
[1] 7817 segmentation fault (core dumped) LD_PRELOAD= uname -a
```
If, instead, libtcmalloc is preloaded first, everything is OK:
```
[~]$ LD_PRELOAD="/usr/lib64/libtcmalloc_debug.so /usr/lib64/torsocks/libtorsocks.so" uname -a
Linux spock 3.19.0-pf3 #1 SMP PREEMPT Tue Mar 24 17:14:04 EET 2015 x86_64 GNU/Linux
```
The problem is that if an app in question is linked against libtcmalloc, torifying it via "torify" or "torsocks" wrapper always leads to segfault because libtorsocks is loaded before libtcmalloc.
Attempt made to debug any app leads to non-informative backtrace:
```
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff725e40c in ?? () from /usr/lib/libtcmalloc_debug.so.4
#2 0x00007ffff725ed3f in ?? () from /usr/lib/libtcmalloc_debug.so.4
#3 0x00007ffff725ef49 in NumCPUs() () from /usr/lib/libtcmalloc_debug.so.4
#4 0x00007ffff723b439 in ?? () from /usr/lib/libtcmalloc_debug.so.4
#5 0x00007ffff7dea1fa in call_init.part () from /lib64/ld-linux-x86-64.so.2
#6 0x00007ffff7dea30b in _dl_init () from /lib64/ld-linux-x86-64.so.2
#7 0x00007ffff7ddbdba in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#8 0x0000000000000003 in ?? ()
#9 0x00007fffffffe47a in ?? ()
#10 0x00007fffffffe4aa in ?? ()
#11 0x00007fffffffe4af in ?? ()
#12 0x0000000000000000 in ?? ()
```
I use torsocks v2.0.0 and libtcmalloc v2.4.
So my questions are:
1. should this be libtorsocks or libtcmalloc issue?
2. how should I get more info on this bug?
3. what should be done to fix the issue?
**Trac**:
**Username**: post-factumDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org