Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T16:09:29Zhttps://gitlab.torproject.org/legacy/trac/-/issues/15504torsocks's getaddrinfo() is broken.2020-06-13T16:09:29ZYawning Angeltorsocks's getaddrinfo() is broken.torsocks's getaddrinfo() implementation does not respect `AI_NUMERICHOST`.
This is wrong because it will do the resolution anyway, and things that expect to be able to use `getaddrinfo()` as a super `inet_pton()` break.
The correct thi...torsocks's getaddrinfo() implementation does not respect `AI_NUMERICHOST`.
This is wrong because it will do the resolution anyway, and things that expect to be able to use `getaddrinfo()` as a super `inet_pton()` break.
The correct thing to do is to check if the string is an address and return `EAI_NONAME` if it's not, without doing the tor resolution.
With this, `#15497` and `#13294` all fixed, `aria2c` actually works with torsocks again, as long as async dns is disabled. Yay.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/15497torsock's getpeername() implementation is broken.2020-06-13T16:09:28ZYawning Angeltorsock's getpeername() implementation is broken.This is incredibly wrong and breaks well written applications:
```
/*
* Extra check for addrlen since we are about to copy the connection
* content into the given address.
*/
if (*addrlen > sizeof(struct ...This is incredibly wrong and breaks well written applications:
```
/*
* Extra check for addrlen since we are about to copy the connection
* content into the given address.
*/
if (*addrlen > sizeof(struct sockaddr)) {
/* Ref to the manpage for the returned value here. */
errno = EINVAL;
ret = -1;
goto end;
}
```
http://pubs.opengroup.org/onlinepubs/9699919799/functions/getpeername.html
>The address_len argument points to a socklen_t object which on input specifies the length of the supplied sockaddr structure, and on output specifies the length of the stored address. If the actual length of the address is greater than the length of the supplied sockaddr structure, the stored address shall be truncated.
This does not mean "reject `address_len` that's larger than `sizeof(struct sockaddr)`", and it is common to pass in a `sockaddr_in6` or `sockaddr_storage` both which are larger than `sockaddr`.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/14322torsocks fails to wrap setcap binaries2020-06-13T16:09:28Zcypherpunkstorsocks fails to wrap setcap binariesthe Linux 'capabilities' library for allowing non-root users to perform tasks which normally require elevated privileges.
at present the torsocks wrappers have checked for setuid and setgid flags on the binaries it executes and failed c...the Linux 'capabilities' library for allowing non-root users to perform tasks which normally require elevated privileges.
at present the torsocks wrappers have checked for setuid and setgid flags on the binaries it executes and failed closed, throwing an error if this occurs, however there is currently no check to see if the binaries have capabilities applied.
in the case where they do, the LD_PRELOAD set by torsocks is stripped and the program will execute with no warning and without the torsocks wrapper.
as an example of this, the current 'ping' command on my Linux is setcap:
$ getcap `which ping`
/usr/bin/ping = cap_net_raw+ep
$ torsocks ping -c 1 torproject.org
PING torproject.org (82.195.75.101) 56(84) bytes of data.
64 bytes from 82.195.75.101: icmp_seq=1 ttl=50 time=38.1 ms
the install script which does setcap || setuid here:
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/iputils.install?h=packages/iputilshttps://gitlab.torproject.org/legacy/trac/-/issues/14281Add option to allow connections to custom local addresses2020-06-13T16:09:27ZDavid Gouletdgoulet@torproject.orgAdd option to allow connections to custom local addressesBring back the torsocks 1.3 option of having a way in the configuration file to define networks/addresses that torsocks is allowed to connect to.
See #8137 for extra information.Bring back the torsocks 1.3 option of having a way in the configuration file to define networks/addresses that torsocks is allowed to connect to.
See #8137 for extra information.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/14268torsocks "make check" target broken in out of tree builds2020-06-13T16:09:27ZYawning Angeltorsocks "make check" target broken in out of tree buildsShould be obvious from the summary, but this fails, when it shouldn't:
```
$ sh autogen.sh
$ mkdir build
$ cd build
$ ../configure; make; make check
```
The failures happen because the build system assumes that the following files are p...Should be obvious from the summary, but this fails, when it shouldn't:
```
$ sh autogen.sh
$ mkdir build
$ cd build
$ ../configure; make; make check
```
The failures happen because the build system assumes that the following files are present under the location that make was run from:
* tests/run.sh
* tests/test_list
* tests/unit/fixtures
Copying the files manually to the right places under "build" fixes things, so this should be easy to fix.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/14265Torsocks works badly with default VirtualAddrNetworkIPv4 ranges2020-06-13T16:09:26ZNick MathewsonTorsocks works badly with default VirtualAddrNetworkIPv4 rangesIn comment:9:ticket:7555 , aagbsn notes that you get the following warning when you use a default AutoMap configuration with IPv4:
```
05:53:37 libtorsocks(13692): connect: Connection is to a local address (127.192.0.1),
may be a TCP DN...In comment:9:ticket:7555 , aagbsn notes that you get the following warning when you use a default AutoMap configuration with IPv4:
```
05:53:37 libtorsocks(13692): connect: Connection is to a local address (127.192.0.1),
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.
```
When AutomapHostsOnResolve is enabled, then Tor returns phony DNS addresses in the "Virtual range" (VirtualAddrNetworkIPv4, VirtualAddrNetworkIPv6) in response to requests for hosts listed in AutomapHostsSuffixes. For example, foobar.onion might resolve into 127.192.66.55, and subsequent connection attempts to 127.192.66.55 will cause Tor to make a connection to foobar.onion.
By default, VirtualAddrNetworkIPv4 is 127.192.0.0/10 and VirtualAddrNetworkIPv6 is [FE80::]/10 . It looks like torsocks rejects the IPv4 one because it's a local address? There should probably be some way to make it not do that, or to make an exception for a certain range, or something.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/14210Enhance torsocks with ControlPort GETINFO communication skills and additional...2020-06-13T16:09:26ZTracEnhance torsocks with ControlPort GETINFO communication skills and additional Socks* optionsUse ControlPort access in Torsocks to GETINFO and attempt preferred transports first. This includes the #12585 SocksSocket and #14209 SocksNamedPipe communication paths to Tor process.
**Trac**:
**Username**: anonUse ControlPort access in Torsocks to GETINFO and attempt preferred transports first. This includes the #12585 SocksSocket and #14209 SocksNamedPipe communication paths to Tor process.
**Trac**:
**Username**: anonDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/14166torsock's configure.ac: avoid tests which have both -pie and -static2020-06-13T16:09:25ZAnthony Basiletorsock's configure.ac: avoid tests which have both -pie and -staticBuilding and linking with both -pie and -static is not supported for some toolchain combinations (eg. glibc or binutil's gold). Yet this combination is hit if the check for gcc hardening is done before AC_PROG_LIBTOOL and AC_ENABLE_STAT...Building and linking with both -pie and -static is not supported for some toolchain combinations (eg. glibc or binutil's gold). Yet this combination is hit if the check for gcc hardening is done before AC_PROG_LIBTOOL and AC_ENABLE_STATIC. We avoid the issue by moving the gcc hardening check to after AC_PROG_LIBTOOL and friends.
See:
https://sourceware.org/bugzilla/show_bug.cgi?id=17826
https://sourceware.org/bugzilla/show_bug.cgi?id=16428
https://bugs.gentoo.org/show_bug.cgi?id=533862David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/14132Add SocksPort Unix support to torsocks2020-06-13T16:09:25ZJacob AppelbaumAdd SocksPort Unix support to torsocksIn Paris, dgoulet and I started to write some basic torsocks support for SocksSocket (#12585) - in an ideal world, we'd have a Tor with a SocksSocket running by default. This would allow torsocks to do useful things by default - namely -...In Paris, dgoulet and I started to write some basic torsocks support for SocksSocket (#12585) - in an ideal world, we'd have a Tor with a SocksSocket running by default. This would allow torsocks to do useful things by default - namely - any app can be instantly torified without worries about firewalls, users can be isolated from different socks proxies by uid, etc. Basically, I think it means that torsocks could default to SocksSocket, if built on a SocksSocket supporting platform.
I think for changes, we'd want to do the following:
Add a configuration (in /etc/torsocks.conf ) option for the default SocksSocket location
eg: /var/lib/tor/SockSocket
stat() the default SocksSocket file location
if we find a SockSocket, we switch to AF_UNIX for all communications
normal torsocks failures from here out
if we don't find a SocksSocket
fail hard? fail soft?
if we fail soft, switch to the default _server_ configured
if that fails, give an error and fail hard
dgoulet - do you still have the patch we started to write in paris?Matthew FinkelMatthew Finkelhttps://gitlab.torproject.org/legacy/trac/-/issues/14021torsocks: remove tsocks from wikistart2020-06-13T16:09:24Zcypherpunkstorsocks: remove tsocks from wikistartRemove the [doc/TSocksPatches](doc/TSocksPatches) entry from [WikiStart](WikiStart), it's no longer relavent since torsocks v2.0.0 release.Remove the [doc/TSocksPatches](doc/TSocksPatches) entry from [WikiStart](WikiStart), it's no longer relavent since torsocks v2.0.0 release.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/13909Torsocks GitHub and Track failed usage2020-06-13T16:09:24ZTracTorsocks GitHub and Track failed usageI try to make working openSUSE RPM with newest Versions
I get failed usage with GitHub or Tor Git version
https://github.com/dgoulet/torsocks
and
https://gitweb.torproject.org/torsocks.git/
I have too tried with mine files to insta...I try to make working openSUSE RPM with newest Versions
I get failed usage with GitHub or Tor Git version
https://github.com/dgoulet/torsocks
and
https://gitweb.torproject.org/torsocks.git/
I have too tried with mine files to install newest Torsocks
```
cat /home/bin/git-/git-Torsocks
#!/bin/sh
echo ""
echo "$0"
echo ""
GIT_Torsocks="/paketi/Net/Sigurnost/Tor/Torsocks/Source/GIT/torsocks"
if [ -d "$GIT_Torsocks" ]
then
cd "$GIT_Torsocks"
echo " -=/\=- Updateing Torsocks -=/\=- "
git pull
else
mkdir -p "$GIT_Torsocks"
cd "$GIT_Torsocks"
cd ..
echo " -=/\=- Download new Torsocks -=/\=- "
git clone https://git.torproject.org/torsocks.git
fi
echo ""
echo " |||+++++----> Done with Torsocks <----+++++||| "
```
And install newest Torsocks with
```
cat /home/bin/install-Torsocks
#!/bin/sh
echo ""
echo "$0"
echo ""
echo ""
/home/bin/git-/git-Torsocks
echo ""
Torsocks=/paketi/Net/Sigurnost/Tor/Torsocks
if [ ! -d $Torsocks/Torsocks ]
then
echo "Copy GIT to $Torsocks/Torsocks"
cd $Torsocks
cp -a ./Source/GIT/torsocks ./Torsocks
echo ""
fi
cd $Torsocks/Torsocks
echo "make uninstall"
make uninstall
echo ""
echo "./autogen.sh"
./autogen.sh
echo ""
echo "./configure"
./configure
echo ""
echo "make"
make
echo "make install"
make install
```
```
which torsocks
/usr/local/bin/torsocks
```
I have too tried with mine files to install newest Tor
```
cat /home/bin/git-/git-Tor
#!/bin/sh
echo ""
echo "$0"
echo ""
GIT_Tor="/paketi/Net/Sigurnost/Tor/Tor/Source/GIT/tor"
if [ -d "$GIT_Tor" ]
then
cd "$GIT_Tor"
echo " -=/\=- Updateing Tor -=/\=- "
git pull
else
mkdir -p "$GIT_Tor"
cd "$GIT_Tor"
cd ..
echo " -=/\=- Download new Tor -=/\=- "
git clone https://git.torproject.org/tor.git
fi
echo ""
echo " |||+++++----> Done with Tor <----+++++||| "
```
And install newest Tor with
Must use with --disable-asciidoc or get 1600 new packages to install :(
```
cat /home/bin/install-Tor
#!/bin/sh
echo ""
echo "$0"
echo ""
echo ""
/home/bin/git-/git-Tor
echo ""
Tor=/paketi/Net/Sigurnost/Tor/Tor
if [ ! -d $Tor/Tor ]
then
echo "Copy GIT to $Tor/Tor"
cd $Tor
cp -a ./Source/GIT/tor ./Tor
echo ""
fi
cd $Tor/Tor
echo "make uninstall"
make uninstall
echo ""
echo "./autogen.sh"
./autogen.sh
echo ""
echo "./configure"
./configure --disable-asciidoc
echo ""
echo "make"
make
echo "make install"
make install
```
```
which tor
/usr/local/bin/tor
```
I try to use my RPM, Source is dowloaded from
https://github.com/dgoulet/torsocks/releases
```
cd var/tmp/build-root/openSUSE_Factory-x86_64/.build.packages/RPMS/x86_64/
```
```
zypper in torsocks-2.0.0-0.x86_64.rpm
```
torsocks-2.0.0-0
```
which torsocks
/usr/bin/torsocks
```
Torsocks newer Versions are not usable at all
```
slogin-tokyoshells-tunnel
[1] 21728 segmentation fault torsocks slogin tokyoshells
```
And all other Applications
```
torsocks smplayer
[1] 22327 segmentation fault torsocks smplayer
```
```
torsocks psi-plus
[1] 22395 segmentation fault torsocks psi-plus
```
...
With older Versions (1.1 and 1.2) from Google Code I not have this failures
https://code.google.com/p/torsocks/
Here are installed working Versions
```
zypper in tor
```
tor-0.2.5.10-70.1
```
which tor
/usr/bin/tor
```
```
zypper in torsocks
```
torsocks-1.1-2.1
```
which torsocks
/usr/bin/torsocks
```
```
zypper in curl
```
curl-7.38.0-1.2
Please correct usage and release one working Torsocks Version.
**Trac**:
**Username**: nemysisDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/13896torsocks prints wrong error messages about setuid/setgid executables2020-06-13T16:09:23ZTractorsocks prints wrong error messages about setuid/setgid executablesTest case:
$ touch foo
$ chmod u+xs foo
$ torsocks ./foo bar
ERROR: ./foo is setbarid. torsocks will not work on a setbarid executable.
“setbarid” is nonsense. The message should read “setuid” instead.
A patch is attached.
**Trac**: ...Test case:
$ touch foo
$ chmod u+xs foo
$ torsocks ./foo bar
ERROR: ./foo is setbarid. torsocks will not work on a setbarid executable.
“setbarid” is nonsense. The message should read “setuid” instead.
A patch is attached.
**Trac**:
**Username**: mitya57David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/13571torsocks doesnt compile under MacOSX 10.10 (SO_DOMAIN linux only?)2020-06-13T16:09:23ZTractorsocks doesnt compile under MacOSX 10.10 (SO_DOMAIN linux only?)Making all in lib
CC recv.lo
clang: warning: argument unused during compilation: '-fno-strict-overflow'
recv.c:73:39: error: use of undeclared identifier 'SO_DOMAIN'
ret = getsockopt(sockfd, SOL_SOCKET, SO_DOMAIN, &sock_d...Making all in lib
CC recv.lo
clang: warning: argument unused during compilation: '-fno-strict-overflow'
recv.c:73:39: error: use of undeclared identifier 'SO_DOMAIN'
ret = getsockopt(sockfd, SOL_SOCKET, SO_DOMAIN, &sock_domain, &optlen);
^
1 error generated.
make[2]: *** [recv.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
**Trac**:
**Username**: olegbDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/13294futex support2020-06-13T16:09:22ZTracfutex supporttorsocks v2.0.0 with irssi-0.8.17-head 20140731 works on first connect, but whines syscall 202 (futex on x86_64) is not supported; on reconnect it goes into infinite loop.
```
Thread 2 (Thread 0x7f959ae1c700 (LWP 10592)):
#0 0x00007f95...torsocks v2.0.0 with irssi-0.8.17-head 20140731 works on first connect, but whines syscall 202 (futex on x86_64) is not supported; on reconnect it goes into infinite loop.
```
Thread 2 (Thread 0x7f959ae1c700 (LWP 10592)):
#0 0x00007f95a18b07cd in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007f95a27089f4 in g_main_context_poll (priority=2147483647, n_fds=1, fds=0x7f95940008e0, timeout=-1, context=0x1d932d0) at gmain.c:4076
#2 g_main_context_iterate (context=context@entry=0x1d932d0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3776
#3 0x00007f95a2708afc in g_main_context_iteration (context=0x1d932d0, may_block=may_block@entry=1) at gmain.c:3842
#4 0x00007f95a2708b39 in glib_worker_main (data=<optimized out>) at gmain.c:5589
#5 0x00007f95a2736d05 in g_thread_proxy (data=0x1d9b400) at gthread.c:764
#6 0x00007f95a2c11f35 in start_thread (arg=0x7f959ae1c700) at pthread_create.c:309
#7 0x00007f95a18bac3d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Thread 1 (Thread 0x7f95a42c2740 (LWP 10589)):
#0 0x00007f95a2c18bdb in __libc_recv (fd=fd@entry=4, buf=buf@entry=0x7fff37e591d0, n=n@entry=10, flags=-1, flags@entry=0) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33
#1 0x00007f95a3f5ac44 in recv_data_impl (fd=4, buf=0x7fff37e591d0, len=<optimized out>) at socks5.c:45
#2 0x00007f95a3f5b66d in socks5_recv_connect_reply (conn=conn@entry=0x22444a0) at socks5.c:498
#3 0x00007f95a3f5638f in tsocks_connect_to_tor (conn=conn@entry=0x22444a0) at torsocks.c:441
#4 0x00007f95a3f56d13 in tsocks_connect (sockfd=sockfd@entry=4, addr=addr@entry=0x7fff37e59280, addrlen=<optimized out>) at connect.c:190
#5 0x00007f95a3f56f1d in connect (sockfd=sockfd@entry=4, addr=addr@entry=0x7fff37e59280, addrlen=<optimized out>) at connect.c:225
#6 0x000000000049465d in net_connect_ip (ip=ip@entry=0x7fff37e593a0, port=port@entry=6697, my_ip=<optimized out>, my_ip@entry=0x0) at network.c:212
#7 0x00000000004a50af in net_connect_ip_ssl (ip=ip@entry=0x7fff37e593a0, port=6697, my_ip=my_ip@entry=0x0, server=server@entry=0x1d99d30) at network-openssl.c:559
#8 0x0000000000499666 in server_real_connect (server=server@entry=0x1d99d30, ip=ip@entry=0x7fff37e593a0, unix_socket=unix_socket@entry=0x0) at servers.c:227
#9 0x0000000000499b2f in server_connect_callback_readpipe (server=0x1d99d30) at servers.c:317
#10 0x0000000000490943 in irssi_io_invoke (source=<optimized out>, condition=<optimized out>, data=<optimized out>) at misc.c:54
#11 0x00007f95a27086cb in g_main_dispatch (context=0x1c61a40) at gmain.c:3111
#12 g_main_context_dispatch (context=context@entry=0x1c61a40) at gmain.c:3710
#13 0x00007f95a2708a58 in g_main_context_iterate (context=context@entry=0x1c61a40, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3781
#14 0x00007f95a2708afc in g_main_context_iteration (context=0x1c61a40, context@entry=0x0, may_block=may_block@entry=1) at gmain.c:3842
#15 0x0000000000416bf2 in main (argc=<optimized out>, argv=0x7fff37e596c8) at irssi.c:373
[pid 20316] 15:47:04.684643 recvfrom(4, 0x7fff1a57a880, 10, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000009>
[pid 20316] 15:47:04.684681 recvfrom(4, 0x7fff1a57a880, 10, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000009>
[pid 20316] 15:47:04.684718 recvfrom(4, 0x7fff1a57a880, 10, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000009>
[pid 20316] 15:47:04.684756 recvfrom(4, 0x7fff1a57a880, 10, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000010>
```
**Trac**:
**Username**: SafariDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/13256torsocks 1.3 possibly leaks username2020-06-13T16:09:21ZTractorsocks 1.3 possibly leaks usernameHi!
Disclaimer:
Not sure if I should have opened this bug report since it's for an old version and torsocks is now on 2.0, but 1.3 is the current version of torsocks in the Ubuntu 14.04 (LTS) repositories, which means it will still be s...Hi!
Disclaimer:
Not sure if I should have opened this bug report since it's for an old version and torsocks is now on 2.0, but 1.3 is the current version of torsocks in the Ubuntu 14.04 (LTS) repositories, which means it will still be so for some time.
Recently while playing with torsocks, wget and wireshark, I discovered something that looks like the name of the user running torsocks is leaked somehow. It's reproducible always that https is not used and torsocks is configured to use SOCKS4 (SOCKS5 unaffected). Please see the attached a screenshot for easier explanation.
Thankfully, these bytes won't leave the loopback interface hardly ever thanks to the default configuration of Tor, but in some configurations it could be considered dangerous. Furthermore, doc/socks/socks-extensions.txt says that usernames are ignored in SOCKS4 and SOCKS4A. Isn't it better to send random characters then instead of the user running it?
I haven't had a deep look at the torsocks code but I think these calls are the key :
src/socks.c: user = getpwuid(getuid());
These calls seem that were there since the beginning of the project but are not anymore in the latest version.
If you considered this is a bug, we should notify distributions. Otherwise if this behaviour is expected, just close this report ;)
**Trac**:
**Username**: p4blogDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/13184Add an option to whitelist networks2020-06-13T16:09:20ZDavid Gouletdgoulet@torproject.orgAdd an option to whitelist networksThis warning is possible for anything socket trying to connect to a localhost address.
`WARNING torsocks[12360]: [connect] Connection to a local address are denied since it might be a TCP DNS query to a local DNS server. Rejecting it fo...This warning is possible for anything socket trying to connect to a localhost address.
`WARNING torsocks[12360]: [connect] Connection to a local address are denied since it might be a TCP DNS query to a local DNS server. Rejecting it for safety reasons. (in tsocks_connect() at connect.c:177)`
We should implement a whitelist mechanism so the user can tell which local network is allowed such as localhost.https://gitlab.torproject.org/legacy/trac/-/issues/11810Connection through torsocks(1) impossible2020-06-13T16:09:20ZTracConnection through torsocks(1) impossibleAfter installing the recent Ubuntu 14.04 AMD64 desktop release (LTS) I went about testing tor(1) and torsocks(1) and saw this:
WITHOUT TOR
$svn co http://svn.apache.org/repos/asf/subversion/trunk subversion
A subversion/notes
A s...After installing the recent Ubuntu 14.04 AMD64 desktop release (LTS) I went about testing tor(1) and torsocks(1) and saw this:
WITHOUT TOR
$svn co http://svn.apache.org/repos/asf/subversion/trunk subversion
A subversion/notes
A subversion/notes/commit-access-templates
A subversion/notes/api-errata
A subversion/notes/api-errata/1.7
A subversion/notes/api-errata/1.8
[...]
WITH TOR
$torsocks svn co http://svn.apache.org/repos/asf/subversion/trunk subversion
svn: E120108: Unable to connect to a repository at URL 'http://svn.apache.org/repos/asf/subversion/trunk'
svn: E120108: Error running context: The server unexpectedly closed the connection.
Since the OS installation is brand new and plain vanilla (no network bridges, VPNs, custom routing, or even a single service configured except for Tor) it seems a problem lies in the Tor software (either the service itself or the Socks wrapper.)
IMPORTANT CLUE
The svn(1) symptom above does not appear when replacing with git(1).
DIAGNOSIS
Running commands through torsocks(1) showing the symptom while inspecting with strace(1) reveals typical socket(2), fcntl(2), fstat(2), setsockopt(2), getpeername(2), and connect(2) to a tor(1) service running on localhost:9050 as usual. What might be atypical is that ENOTCONN and EINPROGRESS are returned in the way indicated by bug #8066 [1]. A late comment in #8066 refers in turn to #3711 [2], which are both leads.
[1] https://trac.torproject.org/projects/tor/ticket/8066/
[2] https://trac.torproject.org/projects/tor/ticket/3711/
LINUX DISTROS
Due to time constraints, I wasn't able to build tor(1) and torsocks(1) from source (at git.torproject.org) so there's a small chance that the bug has been fixed although no bug report exists to support this theory. It doesn't solve the problem of integrating whichever solution exists into leading Linux distributions however, which are still bundling the flawed version.
**Trac**:
**Username**: michaelDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/11727Support shared onion pool for DNS resolution in separate process2020-06-13T16:09:19ZDavid Gouletdgoulet@torproject.orgSupport shared onion pool for DNS resolution in separate processSo it turns out that in irssi is doing DNS resolution in an other process and passing the result back to the first process which will make the connection.
This means that the two process have two distinct onion pools so the process doin...So it turns out that in irssi is doing DNS resolution in an other process and passing the result back to the first process which will make the connection.
This means that the two process have two distinct onion pools so the process doing the DNS resolution will store the onion address with the reserved cookie but the other process, when connecting using that cookie, will be unable to find the onion address in its pool.
One solution I have in mind is to create that onion pool in a shared memory (SHM) and hijack the clone/fork symbol so when we detect a new process we can set the onion pool reference in it thus sharing the pool across processes that have a common parent.
I have a PoC that works but maybe there could be an IPC approach instead.https://gitlab.torproject.org/legacy/trac/-/issues/11726choosing ip / port by command line2020-06-13T16:09:19ZDavid Gouletdgoulet@torproject.orgchoosing ip / port by command lineIt would be great if users could choose ip / port using the command line for easier stream isolation.
Note that for that -u/-p is available on the command line for stream isolation with SOCKS5 authentication method.It would be great if users could choose ip / port using the command line for easier stream isolation.
Note that for that -u/-p is available on the command line for stream isolation with SOCKS5 authentication method.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/11725Support the complete list of dangerous syscall numbers with syscall()2020-06-13T16:09:18ZDavid Gouletdgoulet@torproject.orgSupport the complete list of dangerous syscall numbers with syscall()This is OS specific.This is OS specific.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org