Torsocks issueshttps://gitlab.torproject.org/tpo/core/torsocks/-/issues2024-03-11T22:08:59Zhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/40019torsocks v2.4.0 claims to be v2.3.02024-03-11T22:08:59ZLPkkjHDtorsocks v2.4.0 claims to be v2.3.0When using torsocks v2.4.0 it claims to be v2.3.0 instead:
```
~$ torsocks
torsocks 2.3.0
[...]
~$ torsocks --version
Torsocks 2.3.0
```
Noticed this behavior in a downstream package over at debian/stable.
Compiled from source (afe9dea5...When using torsocks v2.4.0 it claims to be v2.3.0 instead:
```
~$ torsocks
torsocks 2.3.0
[...]
~$ torsocks --version
Torsocks 2.3.0
```
Noticed this behavior in a downstream package over at debian/stable.
Compiled from source (afe9dea542a8b495dbbbbe5e4b98a33cde06729b) to cross check and it seems this is issue has to be opened here.https://gitlab.torproject.org/tpo/core/torsocks/-/issues/40018run autoupdate to fix autoconf warnings: The macro `AC_CONFIG_HEADER' is obso...2023-09-25T14:39:14Zmilahurun autoupdate to fix autoconf warnings: The macro `AC_CONFIG_HEADER' is obsolete.autoconf warnings
```
configure.ac:14: warning: The macro `AC_CONFIG_HEADER' is obsolete.
configure.ac:14: You should run autoupdate.
./lib/autoconf/status.m4:719: AC_CONFIG_HEADER is expanded from...
configure.ac:14: the top level
conf...autoconf warnings
```
configure.ac:14: warning: The macro `AC_CONFIG_HEADER' is obsolete.
configure.ac:14: You should run autoupdate.
./lib/autoconf/status.m4:719: AC_CONFIG_HEADER is expanded from...
configure.ac:14: the top level
configure.ac:38: warning: The macro `AC_TRY_COMPILE' is obsolete.
configure.ac:38: You should run autoupdate.
./lib/autoconf/general.m4:2847: AC_TRY_COMPILE is expanded from...
configure.ac:38: the top level
configure.ac:47: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:47: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:47: the top level
configure.ac:158: warning: The macro `AC_TRY_COMPILE' is obsolete.
configure.ac:158: You should run autoupdate.
./lib/autoconf/general.m4:2847: AC_TRY_COMPILE is expanded from...
configure.ac:158: the top level
configure.ac:179: warning: The macro `AC_TRY_COMPILE' is obsolete.
configure.ac:179: You should run autoupdate.
./lib/autoconf/general.m4:2847: AC_TRY_COMPILE is expanded from...
configure.ac:179: the top level
configure.ac:232: warning: The macro `AC_LANG_C' is obsolete.
configure.ac:232: You should run autoupdate.
./lib/autoconf/c.m4:72: AC_LANG_C is expanded from...
configure.ac:232: the top level
configure.ac:234: warning: The macro `AC_LIBTOOL_DLOPEN' is obsolete.
configure.ac:234: You should run autoupdate.
config/ltoptions.m4:113: AC_LIBTOOL_DLOPEN is expanded from...
configure.ac:234: the top level
configure.ac:234: warning: AC_LIBTOOL_DLOPEN: Remove this warning and the call to _LT_SET_OPTION when you
configure.ac:234: put the 'dlopen' option into LT_INIT's first parameter.
./lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
config/ltoptions.m4:113: AC_LIBTOOL_DLOPEN is expanded from...
configure.ac:234: the top level
configure.ac:235: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
configure.ac:235: You should run autoupdate.
```
fixed by running `autoupdate`
```diff
diff --git a/configure.ac b/configure.ac
index db11118..fbcbc72 100644
--- a/configure.ac
+++ b/configure.ac
@@ -11,7 +11,7 @@ AC_CANONICAL_HOST
AC_CONFIG_MACRO_DIR([config])
# Create a config.h file to store defines generated by configure
-AC_CONFIG_HEADER([include/config.h])
+AC_CONFIG_HEADERS([include/config.h])
# Try to enable the POSIX extensions.
AC_USE_SYSTEM_EXTENSIONS
@@ -35,8 +35,7 @@ dnl Check if the C compiler accepts -Wall
AC_MSG_CHECKING(if the C compiler accepts -Wall)
OLDCFLAGS="$CFLAGS"
CFLAGS="$CFLAGS -Wall"
-AC_TRY_COMPILE(,,
- [AC_MSG_RESULT(yes)],
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])], [AC_MSG_RESULT(yes)],
[
CFLAGS="$OLDCFLAGS"
AC_MSG_RESULT(no)
@@ -44,7 +43,11 @@ AC_TRY_COMPILE(,,
)
dnl Checks for standard header files.
-AC_HEADER_STDC
+# STDC_HEADERS is obsolete.
+# Autoupdate added the next two lines to ensure that your configure
+# script's behavior did not change. They are probably safe to remove.
+AC_CHECK_INCLUDES_DEFAULT
+AC_PROG_EGREP
AC_CHECK_HEADERS(dlfcn.h sys/syscall.h sys/socket.h arpa/inet.h \
assert.h netdb.h errno.h stdarg.h time.h,,
@@ -155,7 +158,7 @@ darwin*)
AC_MSG_CHECKING(if the linker accepts -dynamiclib)
OLDLDFLAGS="$TORSOCKSLDFLAGS"
TORSOCKSLDFLAGS="$TORSOCKSLDFLAGS -dynamiclib"
- AC_TRY_COMPILE(,, [AC_MSG_RESULT(yes)],
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])], [AC_MSG_RESULT(yes)],
[
TORSOCKSLDFLAGS="$OLDLDFLAGS"
AC_MSG_RESULT(no)
@@ -166,7 +169,7 @@ darwin*)
# AC_MSG_CHECKING(if the linker accepts -multiply_defined suppress)
# OLDLDFLAGS="$LDFLAGS"
# LDFLAGS="$LDFLAGS -multiply_defined suppress"
- # AC_TRY_COMPILE(,,AC_MSG_RESULT(yes),[
+ # AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],[AC_MSG_RESULT(yes)],[
# LDFLAGS="$OLDLDFLAGS"
# AC_MSG_RESULT(no)])
@@ -176,7 +179,7 @@ darwin*)
SHLIB_EXT="so"
LDPRELOAD="LD_PRELOAD"
TORSOCKSLDFLAGS="$TORSOCKSLDFLAGS -single_module"
- AC_TRY_COMPILE(,,
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
[
SHLIB_EXT="dylib"
LDPRELOAD="DYLD_INSERT_LIBRARIES"
@@ -229,7 +232,7 @@ fi
# 8. Clean up and create some supporting scripts from their *.in files
##############################################################################
-AC_LANG_C
+AC_LANG([C])
AC_PROG_CC
AC_LIBTOOL_DLOPEN
AC_PROG_LIBTOOL
```https://gitlab.torproject.org/tpo/core/torsocks/-/issues/40017warning: implicit declaration of function 'conf_file_set_enable_ipv6'2023-09-20T14:40:53Zmilahuwarning: implicit declaration of function 'conf_file_set_enable_ipv6'ideally the build should finish without warnings
```
config-file.c: In function 'parse_config_line':
config-file.c:184:23: warning: implicit declaration of function 'conf_file_set_enable_ipv6' [8;;https://gcc.gnu.org/onlinedocs/gcc/Warn...ideally the build should finish without warnings
```
config-file.c: In function 'parse_config_line':
config-file.c:184:23: warning: implicit declaration of function 'conf_file_set_enable_ipv6' [8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wimplicit-function-declaration-Wimplicit-function-declaration8;;]
184 | ret = conf_file_set_enable_ipv6(tokens[1], config);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
config-file.c: In function 'conf_file_set_socks5_user':
config-file.c:332:9: warning: '__builtin_strncpy' output truncated before terminating nul copying as many bytes from a string as its length [8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-truncation-Wstringop-truncation8;;]
332 | strncpy(config->conf_file.socks5_username, username, strlen(username));
| ^
config-file.c:325:13: note: length computed here
325 | if (strlen(username) > sizeof(config->conf_file.socks5_username)) {
| ^~~~~~~~~~~~~~~~
config-file.c: In function 'conf_file_set_socks5_pass':
config-file.c:364:9: warning: '__builtin_strncpy' output truncated before terminating nul copying as many bytes from a string as its length [8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-truncation-Wstringop-truncation8;;]
364 | strncpy(config->conf_file.socks5_password, password, strlen(password));
| ^
config-file.c:357:13: note: length computed here
357 | if (strlen(password) > sizeof(config->conf_file.socks5_password)) {
| ^~~~~~~~~~~~~~~~
```
[torsocks-2.4.0-unstable-2022-08-09-build.log](/uploads/702c8aab587a699c2634df815788b001/torsocks-2.4.0-unstable-2022-08-09-build.log)https://gitlab.torproject.org/tpo/core/torsocks/-/issues/40015Torsocks does not work with the Scudo memory allocator2023-04-12T14:50:22ZgemrebelTorsocks does not work with the Scudo memory allocatorHey, I tried switching to the scudo memory allocator (it's a hardened malloc
implementation from the LLVM project that's now used as the default malloc on
Android) on my system and torsocks no longer works and attempting to run any
progr...Hey, I tried switching to the scudo memory allocator (it's a hardened malloc
implementation from the LLVM project that's now used as the default malloc on
Android) on my system and torsocks no longer works and attempting to run any
program through it just freezes.
I did some debugging with strace and noticed it was getting stuck on a futex()
call.
```
strace -e futex torsocks curl 1.1.1.1
futex(0x6f36109e488c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=165508, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=165509, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
futex(0x6e8496180684, FUTEX_WAIT_PRIVATE, 1, NULL
```
With some further printf debugging, I narrowed it down to the following code
in `src/lib/torsocks.c`, specifically the dlopen() call:
```c
static void init_libc_symbols(void)
{
int ret;
void *libc_ptr;
dlerror();
libc_ptr = dlopen(LIBC_NAME, RTLD_LAZY);
```
Then I wrote a simple test case to try to reproduce the issue:
```c
#include <dlfcn.h>
int main() {
char* libc_ptr = dlopen("libc.so.6", RTLD_LAZY);
return 0;
}
```
It did not freeze like torsocks did, but it did get me a more complete stack
trace out of strace:
```
strace -e futex -k ./a.out
futex(0x638a2a903684, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> /nix/store/8bmp6r3a0xfha3wj36phlc47clh9w81l-glibc-2.35-224/lib/libc.so.6(__pthread_once_slow+0x110) [0x8e0a0]
> /nix/store/yrlxfw3zh4lhsvmx2xwm6d0damhs6qwl-malloc-provider-scudo/lib/libclang_rt.scudo-x86_64.so(_ZN7__scudo10initThreadEb+0x1e) [0xd29e]
> /nix/store/yrlxfw3zh4lhsvmx2xwm6d0damhs6qwl-malloc-provider-scudo/lib/libclang_rt.scudo-x86_64.so(_ZN7__scudo9Allocator8allocateEmmNS_9AllocTypeEb+0x68c) [0xa04c]
> /nix/store/yrlxfw3zh4lhsvmx2xwm6d0damhs6qwl-malloc-provider-scudo/lib/libclang_rt.scudo-x86_64.so(_ZN7__scudo13scudoAllocateEmmNS_9AllocTypeE+0x2e) [0x659e]
> /nix/store/wvm2hvqdbbsp1f11463mrw8nyv678ipm-gcc-12.2.0-lib/lib/libstdc++.so.6.0.30(_GLOBAL__sub_I_eh_alloc.cc+0x3a) [0xb18aa]
> /nix/store/8bmp6r3a0xfha3wj36phlc47clh9w81l-glibc-2.35-224/lib/ld-linux-x86-64.so.2(call_init+0xbe) [0x5e1e]
> /nix/store/8bmp6r3a0xfha3wj36phlc47clh9w81l-glibc-2.35-224/lib/ld-linux-x86-64.so.2(_dl_init+0x7c) [0x5f0c]
> /nix/store/8bmp6r3a0xfha3wj36phlc47clh9w81l-glibc-2.35-224/lib/ld-linux-x86-64.so.2(_dl_help+0x49a) [0x1d3da]
+++ exited with 0 +++
```
I also tried disabling scudo system-wide and just using LD\_PRELOAD for both
torsocks and scudo:
```bash
LD_PRELOAD="result/lib/torsocks/libtorsocks.so /nix/store/yrlxfw3zh4lhsvmx2xwm6d0damhs6qwl-malloc-provider-scudo/lib/libclang_rt.scudo-x86_64.so" curl 1.1.1.1
LD_PRELOAD="/nix/store/yrlxfw3zh4lhsvmx2xwm6d0damhs6qwl-malloc-provider-scudo/lib/libclang_rt.scudo-x86_64.so result/lib/torsocks/libtorsocks.so" curl 1.1.1.1
```
The order the libraries get LD\_PRELOADed does not seem to matter, it still
freezes the same way in both cases.
I know running scudo on a desktop Linux system is an uncommon use case and this
may actually be a scudo bug, but I'm reporting this in the hopes that somebody
more knowledgeable might look into this and get it fixed.
I have also tested it with GrapheneOS's hardened-malloc and it does not have
the same problem. It seems unique to scudo.
Proxychains and proxychains-ng both work with scudo.https://gitlab.torproject.org/tpo/core/torsocks/-/issues/40013torsocks doesn't work on Mac OS Monterey and higher2023-12-12T18:35:34ZXnDY1torsocks doesn't work on Mac OS Monterey and higherI installed Torsocks 2.3.0 via homebrew, while it could not work properly.
I also compiled torsocks myself with gnu gcc (with 0001-Fix-macros-for-accept4-2.patch). The binary looked good but still didn't working.
By contrast, I can con...I installed Torsocks 2.3.0 via homebrew, while it could not work properly.
I also compiled torsocks myself with gnu gcc (with 0001-Fix-macros-for-accept4-2.patch). The binary looked good but still didn't working.
By contrast, I can confirm the latest `proxychains-ng` works, looks like new DYLD hooking method for OSX Monterey is required for recent Mac OS (https://github.com/rofl0r/proxychains-ng/commit/4a013fe6a59ed30e045301dc636d07a6ed999081)
There's some relative discuss: https://tor.stackexchange.com/questions/23135/torsocks-doesn-t-torify-on-macos
Can someone take a look?https://gitlab.torproject.org/tpo/core/torsocks/-/issues/40011IPv6 name resolution is broken (Resolve destination buffer too small)2022-10-31T20:29:27ZyurivictIPv6 name resolution is broken (Resolve destination buffer too small)```
$ torify wget http://beefy5.nyi.freebsd.org/data/123i386-default/f856159e71bf/logs/liboqs-0.7.2.20220607.log
--2022-07-24 19:22:16-- http://beefy5.nyi.freebsd.org/data/123i386-default/f856159e71bf/logs/liboqs-0.7.2.20220607.log
Reso...```
$ torify wget http://beefy5.nyi.freebsd.org/data/123i386-default/f856159e71bf/logs/liboqs-0.7.2.20220607.log
--2022-07-24 19:22:16-- http://beefy5.nyi.freebsd.org/data/123i386-default/f856159e71bf/logs/liboqs-0.7.2.20220607.log
Resolving beefy5.nyi.freebsd.org (beefy5.nyi.freebsd.org)... 1658715736 ERROR torsocks[21853]: [socks5] Resolve destination buffer too small (in socks5_recv_resolve_reply() at socks5.c:701)
```
Version: 0.4.7.8
FreeBSD 13.1https://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/31365Tor Proxy2021-11-15T16:43:29ZTracTor ProxyI am trying to use a tor proxy on mac to force all of my internet traffic through the tor network. I have followed every guide I could find online, but none of them work. when I go to https://check.torproject.org/ in when not in the tor ...I am trying to use a tor proxy on mac to force all of my internet traffic through the tor network. I have followed every guide I could find online, but none of them work. when I go to https://check.torproject.org/ in when not in the tor browser it still says I'm not connected to tor. I there a way that I can force all of my internet traffic through tor, or is it a lost cause?
**Trac**:
**Username**: EliteNoobhttps://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/29000Let torsocks run from source directory2021-11-15T16:43:26ZtraumschuleLet torsocks run from source directoryI don't know how complicated it is to implement, it can be handy to run torsocks from source to test patches.
src/bin/torsocks is not executable and before running 'make install' it returns:
```
$ sh src/bin/torsocks --version
ERROR: /u...I don't know how complicated it is to implement, it can be handy to run torsocks from source to test patches.
src/bin/torsocks is not executable and before running 'make install' it returns:
```
$ sh src/bin/torsocks --version
ERROR: /usr/local/lib/torsocks/libtorsocks.so does not exist! Try re-installing torsocks.
```https://gitlab.torproject.org/tpo/core/torsocks/-/issues/28999Mention dependencies in INSTALL2021-11-15T16:43:24ZtraumschuleMention dependencies in INSTALLRequirements are listed in README.md but not INSTALL.
```
Requirements
-----------------
- autoconf
- automake
- libtool
- gcc
```Requirements are listed in README.md but not INSTALL.
```
Requirements
-----------------
- autoconf
- automake
- libtool
- gcc
```https://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#26339