Torsocks issueshttps://gitlab.torproject.org/tpo/core/torsocks/-/issues2023-12-12T18:42:35Zhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/40005torsocks compilation fails on macOS2023-12-12T18:42:35ZDimitris Apostoloutorsocks compilation fails on macOS```
/Users/rex/torsocks on branch master rex@MacBook-Pro-2018% ./autogen.sh && ./configure && make -j12
+ '[' '!' -e config ']'
+ autoreconf -i
checking build system type... x86_64-apple-darwin20.2.0
checking host system type... x86_64-a...```
/Users/rex/torsocks on branch master rex@MacBook-Pro-2018% ./autogen.sh && ./configure && make -j12
+ '[' '!' -e config ']'
+ autoreconf -i
checking build system type... x86_64-apple-darwin20.2.0
checking host system type... x86_64-apple-darwin20.2.0
checking target system type... x86_64-apple-darwin20.2.0
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /opt/local/bin/ggrep
checking for egrep... /opt/local/bin/ggrep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for a BSD-compatible install... /opt/local/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /opt/local/bin/gmkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports the include directive... yes (GNU style)
checking whether make supports nested variables... yes
checking dependency style of gcc... gcc3
checking whether make supports nested variables... (cached) yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking whether ln -s works... yes
checking if the C compiler accepts -Wall... yes
checking for ANSI C header files... (cached) yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking sys/syscall.h usability... yes
checking sys/syscall.h presence... yes
checking for sys/syscall.h... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking assert.h usability... yes
checking assert.h presence... yes
checking for assert.h... yes
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking stdarg.h usability... yes
checking stdarg.h presence... yes
checking for stdarg.h... yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking for strcspn... yes
checking for strdup... yes
checking for strerror... yes
checking for strcasecmp... yes
checking for strncasecmp... yes
checking for mmap... yes
checking for munmap... yes
checking for socket... yes
checking for connect... yes
checking for close... yes
checking for syscall... yes
checking for recv... yes
checking for send... yes
checking for memset... yes
checking for memcpy... yes
checking for strlen... yes
checking for strncpy... yes
checking for strcmp... yes
checking for malloc... yes
checking for calloc... yes
checking for strstr... yes
checking for strtoul... yes
checking for free... yes
checking for inet_aton... yes
checking for gethostbyname... yes
checking for library containing dlopen... none required
checking file name of the C library... libSystem.dylib
checking if the linker accepts -dynamiclib... yes
checking if the linker accepts -single_module... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking how to print strings... printf
checking for a sed that does not truncate output... /opt/local/bin/gsed
checking for fgrep... /opt/local/bin/ggrep -F
checking for ld used by gcc... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /opt/local/bin/nm -B
checking the name lister (/opt/local/bin/nm -B) interface... BSD nm
checking the maximum length of command line arguments... 786432
checking how to convert x86_64-apple-darwin20.2.0 file names to x86_64-apple-darwin20.2.0 format... func_convert_file_noop
checking how to convert x86_64-apple-darwin20.2.0 file names to toolchain format... func_convert_file_noop
checking for /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /opt/local/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for -force_load linker flag... yes
checking for dlfcn.h... (cached) yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin20.2.0 dyld
checking how to hardcode library paths into programs... immediate
checking for dlopen in -ldl... yes
checking whether a program can dlopen itself... yes
checking whether a statically linked program can dlopen itself... yes
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether C compiler accepts -fPIE... yes
checking whether C compiler accepts -fwrapv... yes
checking whether C compiler accepts --param ssp-buffer-size=1... yes
checking whether C compiler accepts -fstack-protector-all... yes
checking whether the linker accepts -pie... yes
checking whether the linker accepts -z relro... no
checking whether the linker accepts -z now... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating extras/Makefile
config.status: creating src/Makefile
config.status: creating src/bin/Makefile
config.status: creating src/bin/torsocks
config.status: creating src/common/Makefile
config.status: creating src/lib/Makefile
config.status: creating tests/Makefile
config.status: creating tests/unit/Makefile
config.status: creating tests/utils/Makefile
config.status: creating tests/utils/tap/Makefile
config.status: creating doc/Makefile
config.status: creating include/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
Making all in src
Making all in common
CC log.lo
CC config-file.lo
CC utils.lo
CC compat.lo
CC socks5.lo
CC onion.lo
CC connection.lo
CCLD libcommon.la
Making all in lib
CC torsocks.lo
CC connect.lo
CC gethostbyname.lo
CC getaddrinfo.lo
CC close.lo
CC getpeername.lo
CC socket.lo
CC syscall.lo
CC socketpair.lo
CC recv.lo
CC exit.lo
CC accept.lo
torsocks.c:237:2: error: use of undeclared identifier 'tsocks_libc_accept4'; did you mean 'tsocks_libc_accept'?
tsocks_libc_accept4 = dlsym(libc_ptr, LIBC_ACCEPT4_NAME_STR);
^~~~~~~~~~~~~~~~~~~
tsocks_libc_accept
./torsocks.h:411:8: note: 'tsocks_libc_accept' declared here
extern TSOCKS_LIBC_DECL(accept, LIBC_ACCEPT_RET_TYPE, LIBC_ACCEPT_SIG)
^
./torsocks.h:34:9: note: expanded from macro 'TSOCKS_LIBC_DECL'
type (*tsocks_libc_##name)(sig);
^
<scratch space>:97:1: note: expanded from here
tsocks_libc_accept
^
torsocks.c:237:40: error: use of undeclared identifier 'LIBC_ACCEPT4_NAME_STR'
tsocks_libc_accept4 = dlsym(libc_ptr, LIBC_ACCEPT4_NAME_STR);
^
torsocks.c:239:53: error: use of undeclared identifier 'tsocks_libc_accept4'; did you mean 'tsocks_libc_accept'?
!tsocks_libc_syscall || !tsocks_libc_execve || ! tsocks_libc_accept4) {
^~~~~~~~~~~~~~~~~~~
tsocks_libc_accept
./torsocks.h:411:8: note: 'tsocks_libc_accept' declared here
extern TSOCKS_LIBC_DECL(accept, LIBC_ACCEPT_RET_TYPE, LIBC_ACCEPT_SIG)
^
./torsocks.h:34:9: note: expanded from macro 'TSOCKS_LIBC_DECL'
type (*tsocks_libc_##name)(sig);
^
<scratch space>:97:1: note: expanded from here
tsocks_libc_accept
^
3 errors generated.
make[2]: *** [torsocks.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
```https://gitlab.torproject.org/tpo/core/torsocks/-/issues/34199torsocks irssi weird bug2021-11-15T16:43:35ZTractorsocks irssi weird bugDepending on the arguments to torsocks the output varies even though it shouldn't
case-1: torsocks irssi
`/connect oftc` gives following error
Irssi: Unable to connect server irc.oftc.net port 6697 [Interrupted system call]
case 2: tor...Depending on the arguments to torsocks the output varies even though it shouldn't
case-1: torsocks irssi
`/connect oftc` gives following error
Irssi: Unable to connect server irc.oftc.net port 6697 [Interrupted system call]
case 2: torsocks -d irssi
`/connect oftc` works as expected
I don't think there should be difference in output just because logging is enabled. This just might be the "torsocks uncertainty principle". I think we are onto something. Below I've attached the log dumped on the terminal.
1589343629 DEBUG torsocks[22051]: Logging subsytem initialized. Level 5, file (null), time 1 (in init_logging() at torsocks.c:303)
1589343629 DEBUG torsocks[22051]: Config file not provided by TORSOCKS_CONF_FILE. Using default /etc/torsocks.conf (in config_file_read() at config-file.c:543)
1589343629 DEBUG torsocks[22051]: Config file setting tor address to 127.0.0.1 (in conf_file_set_tor_address() at config-file.c:298)
1589343629 DEBUG torsocks[22051]: Config file setting tor port to 9050 (in conf_file_set_tor_port() at config-file.c:254)
1589343629 DEBUG torsocks[22051]: [config] Onion address range set to 127.42.42.0/24 (in set_onion_info() at config-file.c:108)
1589343629 DEBUG torsocks[22051]: Config file /etc/torsocks.conf opened and parsed. (in config_file_read() at config-file.c:572)
1589343629 DEBUG torsocks[22051]: [fclose] Close caught for fd 3 (in tsocks_fclose() at fclose.c:45)
1589343629 DEBUG torsocks[22051]: [onion] Pool init with subnet 127.42.42.0 and mask 24 (in onion_pool_init() at onion.c:104)
1589343629 DEBUG torsocks[22051]: [onion] Pool initialized with base 0, max_pos 255 and size 8 (in onion_pool_init() at onion.c:132)
1589343629 DEBUG torsocks[22051]: [close] Close caught for fd 3 (in tsocks_close() at close.c:33)
1589343629 DEBUG torsocks[22051]: [close] Close caught for fd 3 (in tsocks_close() at close.c:33)
1589343629 DEBUG torsocks[22051]: [close] Close caught for fd 3 (in tsocks_close() at close.c:33)
1589343629 DEBUG torsocks[22051]: [close] Close caught for fd 5 (in tsocks_close() at close.c:33)
1589343629 DEBUG torsocks[22051]: [close] Close caught for fd 5 (in tsocks_close() at close.c:33)
1589343629 DEBUG torsocks[22051]: [close] Close caught for fd 5 (in tsocks_close() at close.c:33)
1589343629 DEBUG torsocks[22051]: [close] Close caught for fd 5 (in tsocks_close() at close.c:33)
1589343629 DEBUG torsocks[22051]: [close] Close caught for fd 5 (in tsocks_close() at close.c:33)
1589343629 DEBUG torsocks[22051]: [close] Close caught for fd 5 (in tsocks_close() at close.c:33)
1589343629 DEBUG torsocks[22051]: [close] Close caught for fd 5 (in tsocks_close() at close.c:33)
1589343629 DEBUG torsocks[22051]: [close] Close caught for fd 5 (in tsocks_close() at close.c:33)
1589343629 DEBUG torsocks[22051]: [close] Close caught for fd 5 (in tsocks_close() at close.c:33)
1589343629 DEBUG torsocks[22051]: [close] Close caught for fd 5 (in tsocks_close() at close.c:33)
1589343629 DEBUG torsocks[22051]: [close] Close caught for fd 5 (in tsocks_close() at close.c:33)
1589343629 DEBUG torsocks[22051]: [close] Close caught for fd 5 (in tsocks_close() at close.c:33)
1589343629 DEBUG torsocks[22051]: [close] Close caught for fd 5 (in tsocks_close() at close.c:33)
**Trac**:
**Username**: crabhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/32599ERROR: ld.so: object '/usr/lib/torsocks/libtorsocks.so' from LD_PRELOAD canno...2021-11-15T16:43:33ZTracERROR: ld.so: object '/usr/lib/torsocks/libtorsocks.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.When I run the command torsocks playonlinux, playonlinux open successfully, but when I open a game in playonlinux I get these error messages :
"ERROR: ld.so: object '/usr/lib/torsocks/libtorsocks.so' from LD_PRELOAD cannot be preloaded (...When I run the command torsocks playonlinux, playonlinux open successfully, but when I open a game in playonlinux I get these error messages :
"ERROR: ld.so: object '/usr/lib/torsocks/libtorsocks.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/usr/lib/torsocks/libtorsocks.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
1574671114 WARNING torsocks[2613]: [syscall] Unsupported syscall number 158. Denying the call (in tsocks_syscall() at syscall.c:568)
1574671122 WARNING torsocks[2626]: [syscall] Unsupported syscall number 158. Denying the call (in tsocks_syscall() at syscall.c:568)
ERROR: ld.so: object '/usr/lib/torsocks/libtorsocks.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
1574671129 WARNING torsocks[2611]: [syscall] Unsupported syscall number 234. Denying the call (in tsocks_syscall() at syscall.c:568)
1574671129 WARNING torsocks[2611]: [syscall] Unsupported syscall number 200. Denying the call (in tsocks_syscall() at syscall.c:568)"
**Trac**:
**Username**: avasvasafwfhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/32577torsocks is not fully capable of performing required downloads2021-11-15T16:43:31ZTractorsocks is not fully capable of performing required downloadsii torsocks 2.3.0-2 amd64 use SOCKS-friendly applications with Tor
using Debian 10.1.0 live
When I try to shield the necessary downloads of my coreboot firmware source compilation I get the following three types of ...ii torsocks 2.3.0-2 amd64 use SOCKS-friendly applications with Tor
using Debian 10.1.0 live
When I try to shield the necessary downloads of my coreboot firmware source compilation I get the following three types of errors:
1574449473 WARNING torsocks[13517]: [syscall] Unsupported syscall number 332. Denying the call (in tsocks_syscall() at syscall.c:605)
1574449473 WARNING torsocks[13517]: [syscall] Unsupported syscall number 293. Denying the call (in tsocks_syscall() at syscall.c:605)
1574449410 WARNING torsocks[13244]: [syscall] Unsupported syscall number 326. Denying the call (in tsocks_syscall() at syscall.c:605)
The download always hangs in some other position and I have given up to do a secure download for the darp5 firmware. This means that I will have no coreboot firmware since the main installation on my darp5 (downloads and compilation work well there) is bugged with a rootkit as detectable by https://www.elstel.org/debcheckroot/. I can not use the compilation results of a bugged machine.
model: System76 Darter Pro 5
git repository: https://github.com/system76/firmware-open
commands to execute:
torsocks git clone https://github.com/system76/firmware-open
cd firmware-open
git checkout whl-u
torsocks git submodule update --init --recursive --checkout
vim scripts/build.sh # remove +nightly from installer
torsocks scripts/deps.sh
source ?.rustup/env? - look for this command in build.sh
torsocks scripts/build.sh darp5
**Trac**:
**Username**: estellnbhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/32491Build fails with uClibc (and maybe some other non-standard libc's) sometimes2021-11-15T16:43:30ZTracBuild fails with uClibc (and maybe some other non-standard libc's) sometimesIn torsocks' configure.ac, libc_name is determined by means of ldd /usr/bin/yes which is then grepped for libc.
On a uClibc system I use, ldd /usr/bin/yes yields two entries, namely
libc.so.0 => ...
ld64-uClibc.so.0 => ...
The resulti...In torsocks' configure.ac, libc_name is determined by means of ldd /usr/bin/yes which is then grepped for libc.
On a uClibc system I use, ldd /usr/bin/yes yields two entries, namely
libc.so.0 => ...
ld64-uClibc.so.0 => ...
The resulting string begins with quotation mark, ends with quotation mark and contains newline character.
At some point during the configuration process (I have not figured out when exactly), the aforementioned string is trimmed erroneously. In my case, the first line is left out and the second one is discarded. The remaining chunk, with the opening quotation mark but without the closing one, ends up in another configuration file, producing a line like
SOME_VARIABLE="libc.so.0
without the closing quotation mark. Build cannot proceed from there.
The libc determination process thus needs to be improved.
My hotfix was to change
grep 'libc\.'
to
grep '\slibc\.'
but I can't suggest the proper solution as I'm not experienced with shell scripts. I will perform a test if provided with (a link to) a relevant standalone patch for torsocks-2.2.0 or torsocks-2.3.0.
**Trac**:
**Username**: akaterhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/30729Possible memory leak in torsocks 2.2.02021-11-15T16:43:28ZTracPossible memory leak in torsocks 2.2.0valgrind found a possible memory leak in torsocks 2.2.0:
```
==29922== 79 bytes in 8 blocks are definitely lost in loss record 17 of 68
==29922== at 0x483579F: malloc (vg_replace_malloc.c:309)
==29922== by 0x569344A: strdup (strdu...valgrind found a possible memory leak in torsocks 2.2.0:
```
==29922== 79 bytes in 8 blocks are definitely lost in loss record 17 of 68
==29922== at 0x483579F: malloc (vg_replace_malloc.c:309)
==29922== by 0x569344A: strdup (strdup.c:42)
==29922== by 0x484D82A: utils_tokenize_ignore_comments (utils.c:146)
==29922== by 0x484CF88: parse_config_line (config-file.c:134)
==29922== by 0x484CF88: parse_config_file (config-file.c:218)
==29922== by 0x484D423: config_file_read (config-file.c:567)
==29922== by 0x484797E: init_config (torsocks.c:163)
==29922== by 0x484797E: tsocks_init (torsocks.c:328)
==29922== by 0x484DFA5: tsocks_once (compat.c:94)
==29922== by 0x400F259: call_init.part.0 (dl-init.c:72)
==29922== by 0x400F358: call_init (dl-init.c:30)
==29922== by 0x400F358: _dl_init (dl-init.c:119)
==29922== by 0x40010C9: ??? (in /lib64/ld-2.29.so)
```
**Trac**:
**Username**: adYpchttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/29311Unsupported syscall number 427 and 180 on OS X on torsocks 2.2.02021-11-15T16:43:27ZTracUnsupported syscall number 427 and 180 on OS X on torsocks 2.2.0
OS X syscalls:
https://opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/kern/syscalls.master
427 AUE_FSGETPATH ALL { user_ssize_t fsgetpath(user_addr_t buf, size_t bufsize, user_addr_t fsid, uint64_t objid) NO_SYSCALL_STUB; } { priv...
OS X syscalls:
https://opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/kern/syscalls.master
427 AUE_FSGETPATH ALL { user_ssize_t fsgetpath(user_addr_t buf, size_t bufsize, user_addr_t fsid, uint64_t objid) NO_SYSCALL_STUB; } { private fsgetpath (File Manager SPI) }
180 AUE_KDEBUGTRACE ALL { int kdebug_trace(int code, int arg1, int arg2, int arg3, int arg4, int arg5) NO_SYSCALL_STUB; }
These syscalls are needed for some GUI apps.
1549142743 WARNING torsocks[10363]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142743 WARNING torsocks[10363]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142743 WARNING torsocks[10363]: [syscall] Unsupported syscall number 180. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142743 WARNING torsocks[10363]: [syscall] Unsupported syscall number 180. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142743 WARNING torsocks[10363]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142743 WARNING torsocks[10363]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142743 WARNING torsocks[10363]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142743 WARNING torsocks[10363]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142743 WARNING torsocks[10363]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142743 WARNING torsocks[10363]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142743 WARNING torsocks[10363]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142743 WARNING torsocks[10363]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142743 WARNING torsocks[10363]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142744 WARNING torsocks[10364]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142744 WARNING torsocks[10364]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142744 WARNING torsocks[10365]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142744 WARNING torsocks[10365]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142744 WARNING torsocks[10365]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142745 WARNING torsocks[10363]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
1549142745 WARNING torsocks[10363]: [syscall] Unsupported syscall number 427. Denying the call (in tsocks_syscall() at syscall.c:488)
I have not tested on torsocks 2.3.0 as it doesn't build on OS X - see issue legacy/trac#28538
**Trac**:
**Username**: akhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/28688torsocks: Unsupported syscall errors in version 2.3.02022-01-09T03:38:36Zyurivict271torsocks: Unsupported syscall errors in version 2.3.0Copied from the downstream bug report:
```
After upgrading to torsocks-2.3.0, I get an error when using torify:
$ torify git clone https://github.com/freebsd/poudriere.git
1543787510 WARNING torsocks[25796]: [syscall] Unsupported syscal...Copied from the downstream bug report:
```
After upgrading to torsocks-2.3.0, I get an error when using torify:
$ torify git clone https://github.com/freebsd/poudriere.git
1543787510 WARNING torsocks[25796]: [syscall] Unsupported syscall number 20. Denying the call (in tsocks_syscall() at syscall.c:568)
Cloning into 'poudriere'...
1543787510 WARNING torsocks[25796]: [syscall] Unsupported syscall number 2. Denying the call (in tsocks_syscall() at syscall.c:568)
error: cannot fork() for git-remote-https: Function not implemented
The same command works with torsocks 2.2.0.
syscall number 2 is fork. There have been some changes to syscall.c which may cause this issue.
```https://gitlab.torproject.org/tpo/core/torsocks/-/issues/28627[torsocks] AAAA replies from tor not handled2022-06-02T13:51:09ZTrac[torsocks] AAAA replies from tor not handledAs reported on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895903:
_Tor now returns IPv6 addresses when hostnames are resolved, but torsocks cannot handle this case._
To reproduce:
```
torsocks -d nc v6.ipv6-test.com 80
```
''...As reported on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895903:
_Tor now returns IPv6 addresses when hostnames are resolved, but torsocks cannot handle this case._
To reproduce:
```
torsocks -d nc v6.ipv6-test.com 80
```
''
This makes it tricky to use torsocks on domains that will resolve to an AAAA only causing the program to abort with no error message.''
Indeed, in
```
int socks5_send_resolve_request(const char *hostname, struct connection *conn)
```
I see:
```
/* By default we use IPv4 address. */
msg.atyp = SOCKS5_ATYP_DOMAIN;
```
(I've tested it from the command line with torsocks 2.3.0, and it does not work, while using TBB it works fine.)
I'm not sure if this issue is also related to this bug:
https://trac.torproject.org/projects/tor/ticket/25295
**Trac**:
**Username**: uhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/28538[regression] torsocks uses linux-specific tsocks_libc_accept4 on FreeBSD2021-11-15T16:43:19Zyurivict271[regression] torsocks uses linux-specific tsocks_libc_accept4 on FreeBSDSee src/lib/torsocks.c.
Version 2.3.0
```
torsocks.c:237:2: error: use of undeclared identifier 'tsocks_libc_accept4'; did you mean 'tsocks_libc_accept'?
tsocks_libc_accept4 = dlsym(libc_ptr, LIBC_ACCEPT4_NAME_STR);
^...See src/lib/torsocks.c.
Version 2.3.0
```
torsocks.c:237:2: error: use of undeclared identifier 'tsocks_libc_accept4'; did you mean 'tsocks_libc_accept'?
tsocks_libc_accept4 = dlsym(libc_ptr, LIBC_ACCEPT4_NAME_STR);
^~~~~~~~~~~~~~~~~~~
tsocks_libc_accept
./torsocks.h:411:8: note: 'tsocks_libc_accept' declared here
extern TSOCKS_LIBC_DECL(accept, LIBC_ACCEPT_RET_TYPE, LIBC_ACCEPT_SIG)
^
./torsocks.h:34:9: note: expanded from macro 'TSOCKS_LIBC_DECL'
type (*tsocks_libc_##name)(sig);
^
<scratch space>:55:1: note: expanded from here
tsocks_libc_accept
^
torsocks.c:237:40: error: use of undeclared identifier 'LIBC_ACCEPT4_NAME_STR'
tsocks_libc_accept4 = dlsym(libc_ptr, LIBC_ACCEPT4_NAME_STR);
^
torsocks.c:239:53: error: use of undeclared identifier 'tsocks_libc_accept4'; did you mean 'tsocks_libc_accept'?
!tsocks_libc_syscall || !tsocks_libc_execve || ! tsocks_libc_accept4) {
^~~~~~~~~~~~~~~~~~~
tsocks_libc_accept
```https://gitlab.torproject.org/tpo/core/torsocks/-/issues/27920"Resolve destination buffer too small" is unclear2021-11-15T16:43:18Ztraumschule"Resolve destination buffer too small" is unclearDoes torsocks support socks4?
I tried to torify cpan and ran into:
```
$ torsocks cpan instal ...
...
Running make test
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; ...Does torsocks support socks4?
I tried to torify cpan and ran into:
```
$ torsocks cpan instal ...
...
Running make test
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/01_load.t .......... 1/1 IO::Socket::IP v0.38 used as base class
t/01_load.t .......... ok
t/02_new.t ........... ok
t/03_connect.t ....... 1538348508 ERROR torsocks[8443]: [socks5] Resolve destination buffer too small (in socks5_recv_resolve_reply() at socks5.c:707)
t/03_connect.t ....... 1/?
# Failed test 'Socks 4 connect'
# at t/03_connect.t line 22.
# Non-recoverable failure in name resolution
Can't call method "version" on an undefined value at t/03_connect.t line 23.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 22 just after 1.
```
Related: legacy/trac#25599, legacy/trac#26339https://gitlab.torproject.org/tpo/core/torsocks/-/issues/26831Feature: conditionally allow non-localhost inbound connections with command-l...2021-11-15T16:43:14ZTracFeature: conditionally allow non-localhost inbound connections with command-line flagI am able to run ZNC without torsocks. Here's my attempt to proxy ZNC via torsocks:
```
foo@foo:~$ torsocks -d znc
1531790543 DEBUG torsocks[2727]: Logging subsytem initialized. Level 5, file (null), time 1 (in init_logging() at torsocks...I am able to run ZNC without torsocks. Here's my attempt to proxy ZNC via torsocks:
```
foo@foo:~$ torsocks -d znc
1531790543 DEBUG torsocks[2727]: Logging subsytem initialized. Level 5, file (null), time 1 (in init_logging() at torsocks.c:303)
1531790543 DEBUG torsocks[2727]: Config file not provided by TORSOCKS_CONF_FILE. Using default /etc/tor/torsocks.conf (in config_file_read() at config-file.c:543)
1531790543 DEBUG torsocks[2727]: Config file setting tor address to 127.0.0.1 (in conf_file_set_tor_address() at config-file.c:298)
1531790543 DEBUG torsocks[2727]: Config file setting tor port to 9050 (in conf_file_set_tor_port() at config-file.c:254)
1531790543 DEBUG torsocks[2727]: [config] Onion address range set to 127.42.42.0/24 (in set_onion_info() at config-file.c:108)
1531790543 DEBUG torsocks[2727]: Config file /etc/tor/torsocks.conf opened and parsed. (in config_file_read() at config-file.c:572)
1531790543 DEBUG torsocks[2727]: [fclose] Close caught for fd 3 (in tsocks_fclose() at fclose.c:45)
1531790543 DEBUG torsocks[2727]: [onion] Pool init with subnet 127.42.42.0 and mask 24 (in onion_pool_init() at onion.c:104)
1531790543 DEBUG torsocks[2727]: [onion] Pool initialized with base 0, max_pos 255 and size 8 (in onion_pool_init() at onion.c:132)
1531790543 DEBUG torsocks[2727]: [fclose] Close caught for fd 5 (in tsocks_fclose() at fclose.c:45)
[ .. ] Checking for list of available modules...
[ >> ] ok
[ .. ] Opening config [/home/foo/.znc/configs/znc.conf]...
[ >> ] ok
[ .. ] Loading global module [webadmin]...
[ >> ] [/usr/lib/znc/webadmin.so]
[ .. ] Binding to port [+21212]...
1531790543 DEBUG torsocks[2727]: [socket] Creating socket with domain 10, type 1 and protocol 6 (in tsocks_socket() at socket.c:33)
1531790543 DEBUG torsocks[2727]: [listen] Non localhost inbound connection are not allowed. (in tsocks_listen() at listen.c:64)
1531790543 DEBUG torsocks[2727]: [close] Close caught for fd 6 (in tsocks_close() at close.c:33)
[ !! ] Unable to bind [Operation not permitted]
[ ** ] Unrecoverable config error.
1531790543 DEBUG torsocks[2727]: [close] Close caught for fd 5 (in tsocks_close() at close.c:33)
1531790543 DEBUG torsocks[2727]: [onion] Destroying onion pool containing 0 entry (in onion_pool_destroy() at onion.c:148)
1531790543 DEBUG torsocks[2727]: [fclose] Close caught for fd 2 (in tsocks_fclose() at fclose.c:45)
foo@foo:~$
```
**Trac**:
**Username**: dbkaplunhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/26821[torsocks] configure script from the tarball breaks2021-11-15T16:43:13Zyurivict271[torsocks] configure script from the tarball breaksTarball: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.2.0.tar.xz
Build breaks in the FreeBSD port after the configure script run:
```
config.status: executing libtool commands
===> Building for torsocks-2.2.0_1
gmake[2]: ...Tarball: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.2.0.tar.xz
Build breaks in the FreeBSD port after the configure script run:
```
config.status: executing libtool commands
===> Building for torsocks-2.2.0_1
gmake[2]: Entering directory '/usr/ports/net/torsocks/work/torsocks-2.2.0'
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /usr/ports/net/torsocks/work/torsocks-2.2.0/config/missing aclocal-1.15 -I config
/usr/ports/net/torsocks/work/torsocks-2.2.0/config/missing: aclocal-1.15: not found
WARNING: 'aclocal-1.15' is missing on your system.
You should only need it if you modified 'acinclude.m4' or
'configure.ac' or m4 files included by 'configure.ac'.
The 'aclocal' program is part of the GNU Automake package:
<http://www.gnu.org/software/automake>
It also requires GNU Autoconf, GNU m4 and Perl in order to run:
<http://www.gnu.org/software/autoconf>
<http://www.gnu.org/software/m4/>
<http://www.perl.org/>
gmake[2]: *** [Makefile:411: aclocal.m4] Error 127
```
Autoreconf though generates the non-breaking configure script.
Something is wrong with this configure, or something is missing, not sure.https://gitlab.torproject.org/tpo/core/torsocks/-/issues/26580torsocks complains about unknown system call #417 on FreeBSD2021-11-15T16:43:11Zyurivict271torsocks complains about unknown system call #417 on FreeBSDCommand:
```
torify telnet {some-onion}.onion {some port}
```
When it connects, pressing Ctrl-C prints this error:
```
^C1530319165 WARNING torsocks[69407]: [syscall] Unsupported syscall number 417. Denying the call (in tsocks_syscall(...Command:
```
torify telnet {some-onion}.onion {some port}
```
When it connects, pressing Ctrl-C prints this error:
```
^C1530319165 WARNING torsocks[69407]: [syscall] Unsupported syscall number 417. Denying the call (in tsocks_syscall() at syscall.c:496)
```
and telnet doesn't exit.
torsocks-2.2.0 on FreeBSD 11.1https://gitlab.torproject.org/tpo/core/torsocks/-/issues/24116Torsocks deadlocks every Rust program2021-11-15T16:43:09ZTracTorsocks deadlocks every Rust programAny Rust program that is run with torsocks will deadlock. This has nothing to do with networking, even the program 'fn main() { }' compiled with a recent rustc will deadlock when run as 'torsocks ./rust_torsocks'.
This is a backtrace I ...Any Rust program that is run with torsocks will deadlock. This has nothing to do with networking, even the program 'fn main() { }' compiled with a recent rustc will deadlock when run as 'torsocks ./rust_torsocks'.
This is a backtrace I got when attaching to the deadlocked process:
```
#0 0xb7713cf9 in __kernel_vsyscall ()
#1 0xb76b9d92 in __lll_lock_wait ()
at ../sysdeps/unix/sysv/linux/i386/lowlevellock.S:144
#2 0xb76b38de in __GI___pthread_mutex_lock (mutex=0xb770d024)
at ../nptl/pthread_mutex_[lock.c:80 lock.c:80]
#3 0xb77001ed in tsocks_mutex_lock ()
from /usr/lib/i386-linux-gnu/torsocks/libtorsocks.so
#4 0xb7700334 in tsocks_once ()
from /usr/lib/i386-linux-gnu/torsocks/libtorsocks.so
#5 0xb76fa25e in tsocks_initialize ()
from /usr/lib/i386-linux-gnu/torsocks/libtorsocks.so
#6 0xb76fd02d in syscall ()
from /usr/lib/i386-linux-gnu/torsocks/libtorsocks.so
#7 0x004a5049 in os_overcommits_proc ()
at /checkout/src/liballoc_jemalloc/../jemalloc/src/pages.c:252
#8 je_pages_boot ()
at /checkout/src/liballoc_jemalloc/../jemalloc/src/pages.c:297
#9 0x004745dd in malloc_init_hard_a0_locked ()
at /checkout/src/liballoc_jemalloc/../jemalloc/src/jemalloc.c:1366
#10 0x00474768 in malloc_init_hard ()
at /checkout/src/liballoc_jemalloc/../jemalloc/src/jemalloc.c:1493
#11 0x00489b95 in malloc_init ()
at /checkout/src/liballoc_jemalloc/../jemalloc/src/jemalloc.c:317
#12 ialloc_body (slow_path=true, usize=<synthetic pointer>,
tsdn=<synthetic pointer>, zero=true, size=20)at /checkout/src/liballoc_jemalloc/../jemalloc/src/jemalloc.c:1583
#13 calloc (num=1, size=20)
at /checkout/src/liballoc_jemalloc/../jemalloc/src/jemalloc.c:1824
#14 0xb76d23ec in _dlerror_run (
operate=operate@entry=0xb76d1b80 <dlopen_doit>, args=args@entry=0xbfb8cd10)
#15 0xb76d1c9e in __dlopen (file=0xb7703345 "libc.so.6", mode=1) at dlopen.c:87
#16 0xb76fa44f in ?? () from /usr/lib/i386-linux-gnu/torsocks/libtorsocks.so
#17 0xb7700352 in tsocks_once ()__
from /usr/lib/i386-linux-gnu/torsocks/libtorsocks.so
#18 0xb76fa25e in tsocks_initialize ()
from /usr/lib/i386-linux-gnu/torsocks/libtorsocks.so
#19 0xb7724c65 in call_init (l=<optimized out>, argc=argc@entry=1,
argv=argv@entry=0xbfb8ce74, env=0xbfb8ce7c) at dl-init.c:72
#20 0xb7724d8e in call_init (env=0xbfb8ce7c, argv=0xbfb8ce74, argc=1,
l=<optimized out>) at dl-init.c:30
#21 _dl_init (main_map=<optimized out>, argc=1, argv=0xbfb8ce74,
env=0xbfb8ce7c) at dl-init.c:120
#22 0xb7715a5f in _dl_start_user () from /lib/ld-linux.so.2
```
It looks like tsocks_initialize() is called when libtorsocks is loaded, it calls tsocks_once() which locks a mutex and then calls dlopen() to get the libc symbols, dlopen() tries to allocate some memory which leads jemalloc (the default allocator for Rust programs) to try to call syscall() (it wants to open a proc file to see if the system overcommits memory or not), which is intercepted by libtorsocks, which leads to another call to tsocks_initialize()... and since the mutex is already locked, it deadlocks.
One way to fix this might be to just let through any syscall() calls that happen during bootstrapping, but i don't know the torsocks code well enough to know if this could cause any dangerous leaks.
**Trac**:
**Username**: larslhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/23872torsocks hangs recent firefox versions2021-11-15T16:43:07Zcypherpunkstorsocks hangs recent firefox versionsFirefox 52.4.0 (and the ESR variant) hang if launched as:
"torsocks firefox"
It's similar to this old bug:
https://trac.torproject.org/projects/tor/ticket/12119
End of the strace looks like this:
getrlimit(RLIMIT_STACK, {rlim_c...Firefox 52.4.0 (and the ESR variant) hang if launched as:
"torsocks firefox"
It's similar to this old bug:
https://trac.torproject.org/projects/tor/ticket/12119
End of the strace looks like this:
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
readlink("/etc/malloc.conf", 0x7ffdbbb59657, 4096) = -1 ENOENT (No such file or directory)
getuid() = 1000
geteuid() = 1000
futex(0x7f76ce5460a8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x55b36758c320, FUTEX_WAIT_PRIVATE, 2, NULLhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/19700torsocks does not work with "connectx" (in netcat / nc)2021-11-15T16:43:02ZTractorsocks does not work with "connectx" (in netcat / nc)I found that 'torify', which wraps connections outbound through Tor, did not work with "nc" (netcat) on Mac OS X in that connections exposed my true IP address. I looked further into it, and torify works with the flag to "-O" in nc (nc -...I found that 'torify', which wraps connections outbound through Tor, did not work with "nc" (netcat) on Mac OS X in that connections exposed my true IP address. I looked further into it, and torify works with the flag to "-O" in nc (nc -O) which, according to the usage, utilizes the standard connect() system call. However, by default, netcat seems to be now using the "connectx" system call which torsocks is not hooking. I cannot find much information on "connectx" except that related to the protocol "SCTP" on BSD variants (including OS X).
Does anyone know anything about this? Is there any plans to hook calls to "connectx()" (or, from what I've found, sctp_connectx() is the call)? The protocol shows up as "tcp4" in a netstat on OS X.
nc usage flag info for -O:
-O Use old-style connect instead of connectx
**Trac**:
**Username**: egonlinehttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/16934youtube-dl (recent), torsocks 2.1.0 and TBB5+ failure2021-11-15T16:42:59ZTracyoutube-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/tpo/core/torsocks/-/issues/14322torsocks fails to wrap setcap binaries2021-11-15T16:42:58Zcypherpunkstorsocks 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/iputils