Torsocks issueshttps://gitlab.torproject.org/tpo/core/torsocks/-/issues2020-06-27T14:12:09Zhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/16432patches for NetBSD2020-06-27T14:12:09Zcypherpunkspatches 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/tpo/core/torsocks/-/issues/16349Need to merge GigHub pull requests2020-06-27T14:12:09Zyurivict271Need 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/tpo/core/torsocks/-/issues/16308Attempts to resolve local hostname using tor2020-06-27T14:12:09ZTracAttempts 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/tpo/core/torsocks/-/issues/16223Torsocks v2.1.0 fails to build on RHEL/CentOS 5.x2020-06-27T14:12:09ZTracTorsocks 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/tpo/core/torsocks/-/issues/16183torsocks upgrade broke OpenSSH connection sharing2020-06-27T14:12:09ZTractorsocks 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/tpo/core/torsocks/-/issues/15584Linking libtorsocks with libtcmalloc results in SIGSEGV2021-07-09T18:32:02ZTracLinking 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.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/15504torsocks's getaddrinfo() is broken.2020-06-27T14:12:09ZYawning 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/tpo/core/torsocks/-/issues/15497torsock's getpeername() implementation is broken.2020-06-27T14:12:10ZYawning 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/tpo/core/torsocks/-/issues/14268torsocks "make check" target broken in out of tree builds2020-06-27T14:12:10ZYawning 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/tpo/core/torsocks/-/issues/14265Torsocks works badly with default VirtualAddrNetworkIPv4 ranges2020-06-27T14:12:10ZNick 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/tpo/core/torsocks/-/issues/14166torsock's configure.ac: avoid tests which have both -pie and -static2020-06-27T14:12:10ZAnthony 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/tpo/core/torsocks/-/issues/13909Torsocks GitHub and Track failed usage2020-06-27T14:12:11ZTracTorsocks 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/tpo/core/torsocks/-/issues/13896torsocks prints wrong error messages about setuid/setgid executables2020-06-27T14:12:11ZTractorsocks 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/tpo/core/torsocks/-/issues/13571torsocks doesnt compile under MacOSX 10.10 (SO_DOMAIN linux only?)2020-06-27T14:12:11ZTractorsocks 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/tpo/core/torsocks/-/issues/13294futex support2020-06-27T14:12:11ZTracfutex 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/tpo/core/torsocks/-/issues/13256torsocks 1.3 possibly leaks username2020-06-27T14:12:11ZTractorsocks 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/tpo/core/torsocks/-/issues/11810Connection through torsocks(1) impossible2020-06-27T14:12:12ZTracConnection 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 legacy/trac#8066 [1]. A late comment in legacy/trac#8066 refers in turn to legacy/trac#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/tpo/core/torsocks/-/issues/11541torsocks Does Not Work with dig on Fedora 202020-06-27T14:12:12ZTractorsocks Does Not Work with dig on Fedora 20I am trying to follow the nmap-ncat instructions here https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/ssh for connecting to a tor hidden service over SSH. I can't seem to get it working. This is what I execute "torsocks d...I am trying to follow the nmap-ncat instructions here https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/ssh for connecting to a tor hidden service over SSH. I can't seem to get it working. This is what I execute "torsocks dig @213.73.91.35 +tcp +short www.google.com" which returns ";; communications error to 213.73.91.35#53: end of file". When I execute "dig @213.73.91.35 +tcp +short www.google.com" without torsocks, IP addresses are returned. I have verified I am connected to tor via setting up my Firefox (not tor browser bundle) proxy settings and going to check.torproject.org.
I am on Fedora 20. I am using tor version tor.x86_64-0.2.4.21-tor.1.rh20 and torsocks version torsocks.x86_64-1.3-2.fc20. You can contact me at eviljoel@linux.com if you have any questions.
**Trac**:
**Username**: eviljoelDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/11456'make test' should run the tests2020-06-27T14:12:12ZRoger Dingledine'make test' should run the teststorsocks appears to have tests in its tests/ directory. There's even a tests/run.sh that, when I run it, gives me a cryptic statement about testlists, but no hint about where I can find a testlist. How do I run them?
And can we hook tha...torsocks appears to have tests in its tests/ directory. There's even a tests/run.sh that, when I run it, gives me a cryptic statement about testlists, but no hint about where I can find a testlist. How do I run them?
And can we hook that up to a 'make test' in the main directory?
Thanks!David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/11205[PATCH] gethostbyname2 needs to be supported in addition to gethostbyname2020-06-27T14:12:13Zyurivict271[PATCH] gethostbyname2 needs to be supported in addition to gethostbynameRepost of the bug from the old bug repotring system: https://code.google.com/p/torsocks/issues/detail?id=60
On some systems, like FreeBSD, function gethostbyname2(3) is defined in addition to gethostbyname(3). Here is its signature:
...Repost of the bug from the old bug repotring system: https://code.google.com/p/torsocks/issues/detail?id=60
On some systems, like FreeBSD, function gethostbyname2(3) is defined in addition to gethostbyname(3). Here is its signature:
struct hostent *
gethostbyname2(const char *name, int af);
If the process uses gethostbyname2 instead of gethostbyname for the name resolution, it doesn't go through SOCKS5 and connection fails.
Need to support it.
Particularly, mplayer configures itself to use gethostbyname2 on FreeBSD, and therefore by default doesn't work with libtorsocks.
Implemented gethost by name in case of tcp v4, v6 is not yet implemented.
Tested with the streams played by mplayer. DNS resolution works fine.
torsocks-1.2_1Jacob AppelbaumJacob Appelbaum