Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:34:34Zhttps://gitlab.torproject.org/legacy/trac/-/issues/28611Add `-mstack-protector-guard=global` to CFLAGS instead of `--disable-gcc-hard...2020-06-13T15:34:34ZTracAdd `-mstack-protector-guard=global` to CFLAGS instead of `--disable-gcc-hardening` configure option on Windows?workaround https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832#c8
Tor compiles fine on Windows mingw gcc 8.2 without `--disable-gcc-hardening` if add `-mstack-protector-guard=global` to CFLAGS
**Trac**:
**Username**: grjworkaround https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832#c8
Tor compiles fine on Windows mingw gcc 8.2 without `--disable-gcc-hardening` if add `-mstack-protector-guard=global` to CFLAGS
**Trac**:
**Username**: grjTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28522[armhf] (Sandbox) Caught a bad syscall attempt2020-06-13T15:34:22ZTrac[armhf] (Sandbox) Caught a bad syscall attemptHello,
I just come to give the sandbox option in tor´s configuration another try after I had done an update. And learnt that it did not work.
The OS is Debian Stretch on a BananaPi (armhf, 32bit). Kernel is 4.14.70-sunxi armv7l.
```
N...Hello,
I just come to give the sandbox option in tor´s configuration another try after I had done an update. And learnt that it did not work.
The OS is Debian Stretch on a BananaPi (armhf, 32bit). Kernel is 4.14.70-sunxi armv7l.
```
Nov 19 17:13:54 eisbaer Tor[11800]: Tor 0.3.4.9 (git-4ac3ccf2863b86e7) running on Linux with Libevent 2.0.21-stable, OpenSSL LibreSSL 2.8.2, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.1.2.
Nov 19 17:13:54 eisbaer Tor[11800]: Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Nov 19 17:13:54 eisbaer Tor[11800]: Read configuration file "/srv/ursus-tor/etc/tor/torrc".
Nov 19 17:13:54 eisbaer Tor[11800]: Based on detected system memory, MaxMemInQueues is set to 748 MB. You can override this by setting MaxMemInQueues by hand.
Nov 19 17:13:54 eisbaer Tor[11800]: Scheduler type KIST has been enabled.
Nov 19 17:13:54 eisbaer Tor[11800]: Opening Control listener on 127.0.0.1:9051
Nov 19 17:13:54 eisbaer Tor[11800]: Opening Control listener on /srv/ursus-tor/var/run/control
Nov 19 17:13:54 eisbaer Tor[11800]: Opening OR listener on 0.0.0.0:8080
Nov 19 17:23:13 eisbaer Tor[11800]: Parsing GEOIP IPv4 file /srv/ursus-tor/etc/tor/geoip.
Nov 19 17:23:16 eisbaer Tor[11800]: Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
... **without** sandboxing tor starts bootstrapping here ...
Nov 19 17:23:46 eisbaer tor[11800]: ============================================================ T= 1542644626
Nov 19 17:23:46 eisbaer tor[11800]: (Sandbox) Caught a bad syscall attempt (syscall 289)
... according to a syscall list this is "sys_signalfd4" ...
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(+0x1e5fda)[0x67dfda]
Nov 19 17:23:46 eisbaer tor[11800]: /lib/arm-linux-gnueabihf/libc.so.6(__send+0x17)[0xb6d59278]
Nov 19 17:23:46 eisbaer tor[11800]: /lib/arm-linux-gnueabihf/libc.so.6(__send+0x17)[0xb6d59278]
Nov 19 17:23:46 eisbaer tor[11800]: /lib/arm-linux-gnueabihf/libc.so.6(__vsyslog_chk+0x275)[0xb6d55cea]
Nov 19 17:23:46 eisbaer tor[11800]: /lib/arm-linux-gnueabihf/libc.so.6(syslog+0x17)[0xb6d55e98]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(+0x1d4628)[0x66c628]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(+0x1d49dc)[0x66c9dc]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(log_fn_+0x43)[0x66d150]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(sandbox_getaddrinfo+0x173)[0x67db20]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(tor_addr_lookup+0x155)[0x65915a]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(tor_lookup_hostname+0x23)[0x6628b4]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(resolve_my_address+0x175)[0x5c25e2]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(router_pick_published_address+0x43)[0x55266c]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(router_rebuild_descriptor+0x3f)[0x553340]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(router_get_my_routerinfo_with_err+0x47)[0x55241c]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(router_get_my_routerinfo+0x17)[0x5523b0]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(router_get_my_descriptor+0x15)[0x5524a6]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(init_keys+0x419)[0x5508aa]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(do_main_loop+0x77)[0x50f398]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(tor_run_main+0xff)[0x513084]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(tor_main+0x53)[0x50a4d0]
Nov 19 17:23:46 eisbaer tor[11800]: /srv/ursus-tor/bin/tor(main+0x1d)[0x50a34a]
Nov 19 17:23:46 eisbaer tor[11800]: /lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x9d)[0xb6cda4aa]
Nov 19 17:23:47 eisbaer systemd[1]: tor.service: Main process exited, code=exited, status=1/FAILURE
Nov 19 17:23:47 eisbaer systemd[1]: tor.service: Unit entered failed state.
Nov 19 17:23:47 eisbaer systemd[1]: tor.service: Failed with result 'exit-code'.
```
**Trac**:
**Username**: bundesgebaermutterTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28511Limit the number of open testing circuits, and the total number of testing ci...2020-06-13T15:34:19ZteorLimit the number of open testing circuits, and the total number of testing circuitsTor relays can open many more testing circuits than they need:
When Tor is doing its first ORPort reachability test, it initiates one testing circuit after the first successful circuit, then one testing circuit per second until the ORPo...Tor relays can open many more testing circuits than they need:
When Tor is doing its first ORPort reachability test, it initiates one testing circuit after the first successful circuit, then one testing circuit per second until the ORPort is found reachable. Then it gives up after 20 minutes. (1200 circuits is definitely too many.)
When tor receives any descriptor or consensus, it does another ORPort reachability test, and initiates a testing circuit.
When a testing circuit opens, and there aren't enough testing circuits to test bandwidth, then tor initiates another testing circuit.
When a testing circuit expires, tor doesn't stop opening testing circuits to replace it.
We should place a timeout on bandwidth testing (the same as reachability tests?), a limit on the number of in-progress and open testing circuits (NUM_PARALLEL_TESTING_CIRCS*3/2 ?), and a limit on the total number of testing circuits that tor will build over a certain time (NUM_PARALLEL_TESTING_CIRCS*3 an hour?).
We should also reduce the frequency of the initial ORPort testing circuit callback, so those circuits are spread out over the 20 minute ORPort testing interval.
We should be careful to make these limits apply to relays, but not authorities. Authorities need to test a large number of relays every hour.
Edit: suggest some limitsTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28378Add libsystemd-devel to the travis config, if available2020-06-13T15:33:57ZteorAdd libsystemd-devel to the travis config, if availableIn #28113, we discovered that libsystemd-devel was not installed in travis. We should install it, and build with it.
We should probably do #28377 at the same time.In #28113, we discovered that libsystemd-devel was not installed in travis. We should install it, and build with it.
We should probably do #28377 at the same time.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28183tor-0.3.5.3_alpha unexpected stop bug: (Sandbox) Caught a bad syscall attempt...2020-06-13T15:33:18ZTractor-0.3.5.3_alpha unexpected stop bug: (Sandbox) Caught a bad syscall attempt (syscall shutdown)tor -f ./torrc
Oct 24 08:10:51.726 [notice] Tor 0.3.5.3-alpha running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2p, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd N/A.
Oct 24 08:10:51.726 [notice] This version is not a stable Tor releas...tor -f ./torrc
Oct 24 08:10:51.726 [notice] Tor 0.3.5.3-alpha running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2p, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd N/A.
Oct 24 08:10:51.726 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Oct 24 08:10:51.726 [notice] Read configuration file "/home/n05/./torrc".
Oct 24 08:10:51.730 [notice] Opening Socks listener on 127.0.0.1:7012
Oct 24 08:10:51.730 [notice] Opened Socks listener on 127.0.0.1:7012
Oct 24 08:10:51.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Oct 24 08:10:51.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Oct 24 08:10:51.000 [notice] Bootstrapped 0%: Starting
Oct 24 08:10:52.000 [notice] Starting with guard context "default"
Oct 24 08:10:52.000 [notice] Bootstrapped 10%: Finishing handshake with directory server
Oct 24 08:10:52.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Oct 24 08:10:52.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Oct 24 08:10:53.000 [notice] Bootstrapped 100%: Done
============================================================ T= 1540371205
(Sandbox) Caught a bad syscall attempt (syscall shutdown)
tor(+0x7cb9e)[0x559d07c0cb9e]
/lib64/libc.so.6(shutdown+0x7)[0x7f7b36b6ab97]
/lib64/libc.so.6(shutdown+0x7)[0x7f7b36b6ab97]
/usr/lib64/libcrypto.so.1.0.0(+0xf885d)[0x7f7b3738785d]
/usr/lib64/libcrypto.so.1.0.0(BIO_free+0x8a)[0x7f7b3733237a]
/usr/lib64/libcrypto.so.1.0.0(BIO_free_all+0x24)[0x7f7b373920e4]
/usr/lib64/libssl.so.1.0.0(SSL_free+0x97)[0x7f7b37c7ac87]
tor(tor_tls_free_+0x3c)[0x559d07c3f93c]
tor(+0x1c631a)[0x559d07d5631a]
tor(+0x1c1e34)[0x559d07d51e34]
tor(+0x1c228e)[0x559d07d5228e]
/usr/lib64/libevent-2.1.so.6(+0x20b45)[0x7f7b374fbb45]
/usr/lib64/libevent-2.1.so.6(event_base_loop+0x507)[0x7f7b374fc8a7]
tor(do_main_loop+0x74)[0x559d07d4a994]
tor(tor_run_main+0x11a6)[0x559d07d5a9b6]
tor(tor_main+0x26)[0x559d07d5bdc6]
tor(main+0x9)[0x559d07be1be9]
/lib64/libc.so.6(__libc_start_main+0xe7)[0x7f7b36a86ae7]
tor(_start+0x2a)[0x559d07be1c2a]
torrc:
Log notice
#SEC
SandBox 1
SafeLogging 1
NoExec 1
ClientOnly 1
SafeSocks 1
TestSocks 1
#NET
#8min keep-alive
KeepAlivePeriod 600
SOCKSPort 7012
#PERF
TruncateLogFile 1
HardwareAccel 1
#AccelName rdrand
AvoidDiskWrites 1
emerge --info
Portage 2.3.51 (python 3.6.6-final-0, default/linux/amd64/17.0, gcc-8.2.0, glibc-2.27-r6, 4.19.0-gentoo_intel x86_64)
=================================================================
System uname: Linux-4.19.0-gentoo_intel-x86_64-Intel-R-_Core-TM-_i7-2860QM_CPU_@_2.50GHz-with-gentoo-2.6
KiB Mem: 16211896 total, 328624 free
KiB Swap: 15625212 total, 15625212 free
Timestamp of repository gentoo: Wed, 24 Oct 2018 00:45:01 +0000
sh bash 4.4_p23
ld GNU ld (Gentoo 2.31.1 p3) 2.31.1
distcc 3.2rc1 x86_64-pc-linux-gnu [disabled]
ccache version 3.5 [disabled]
app-shells/bash: 4.4_p23::gentoo
dev-java/java-config: 2.2.0-r4::gentoo
dev-lang/perl: 5.26.2::gentoo
dev-lang/python: 2.7.15::gentoo, 3.6.6::gentoo
dev-util/ccache: 3.5::gentoo
dev-util/cmake: 3.12.3::gentoo
dev-util/pkgconfig: 0.29.2::gentoo
sys-apps/baselayout: 2.6-r1::gentoo
sys-apps/openrc: 0.39::gentoo
sys-apps/sandbox: 2.13::gentoo
sys-devel/autoconf: 2.13::gentoo, 2.69-r4::gentoo
sys-devel/automake: 1.16.1-r1::gentoo
sys-devel/binutils: 2.31.1-r1::gentoo
sys-devel/gcc: 8.2.0-r3::gentoo
sys-devel/gcc-config: 2.0::gentoo
sys-devel/libtool: 2.4.6-r5::gentoo
sys-devel/make: 4.2.1-r4::gentoo
sys-kernel/linux-headers: 4.19::gentoo (virtual/os-headers)
sys-libs/glibc: 2.27-r6::gentoo
Repositories:
gentoo
location: /usr/portage
sync-type: webrsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe -flto=8 -fuse-ld=gold -fomit-frame-pointer -ftree-vectorize -march=sandybridge -mtune=sandybridge -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -maes -mpclmul -mpopcnt -mavx -msse4.2 -msse4.1 -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/gnupg/qualified.txt /var/lib/i2pd/certificates"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe -flto=8 -fuse-ld=gold -fomit-frame-pointer -ftree-vectorize -march=sandybridge -mtune=sandybridge -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -maes -mpclmul -mpopcnt -mavx -msse4.2 -msse4.1 -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192"
DISTDIR="/usr/portage/distfiles"
ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs candy cgroup config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news nodoc noinfo noman parallel-fetch parallel-install preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync webrsync-gpg xattr"
FFLAGS="-O2 -pipe"
LANG="en_US.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="en ru ua"
MAKEOPTS="-j8"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="#chromium #graphite #link X a aac acl acpi adjust alsa amd64 avx based bash-completion berkdb branding break, bzip2 cairo can check cli consolekit crypt custom-cflags custom-optimization cxx dbus dri dri3 ffmpeg fortran gallium gdbm gif glamor gnome-keyring graphite gstreamer gtk gtk3 iconv icu intermediate jemalloc jit jpeg jpeg2k jumbo-build jumbo_file_merge_limit libnotify libsamplerate libtirpc llvm lm_sensors lock loop lto lzma lzo make matroska mime mmx mmxext mng mp3 mp4 multilib ncurses networkmanager nls nptl ntp on opengl openmp optimization optimizations pam pclmul pcre png policykit polyhedral popcnt rdesktop readline representation seccomp session shenandoah sndfile socks5 sound speedup, sqlite sse sse2 sse3 sse4_1 sse4_2 ssl ssse3 startup-notification svg system-bzip2 system-ffmpeg system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-libwebp system-lua system-sqlite system-zlib tcpd theora threads thunar tiff time truetype udev udisks unicode upower usb uvm v4l vaapi vdpau vorbis vpx vulkan webp wifi wmf x264 xa xattr xcb xpm xscreensaver xvid xvmc zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon plan sheets stage words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev synaptics" KERNEL="linux" L10N="en ru ua" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-1" POSTGRES_TARGETS="postgres9_5 postgres10" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" QEMU_SOFTMMU_TARGETS="arm" QEMU_USER_TARGETS="arm" RUBY_TARGETS="ruby25" USERLAND="GNU" VIDEO_CARDS="intel i965" XFCE_PLUGINS="brightness clock power trash" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
equery u tor
[ Legend : U - final flag setting for installation]
[ : I - package is installed with flag ]
[ Colors : set, unset ]
* Found these USE flags for net-vpn/tor-0.3.5.3_alpha:
U I
- - caps : Use Linux capabilities library to control privilege
- - libressl : Use dev-libs/libressl instead of dev-libs/openssl when applicable (see also the ssl useflag)
+ + lzma : Support for LZMA (de)compression algorithm
- - scrypt : Use app-crypt/libscrypt for the scrypt algorithm
+ + seccomp : Enable seccomp (secure computing mode) to perform system call filtering at runtime to increase security of programs
- - systemd : Enable use of systemd-specific libraries and features like socket activation or session tracking
- - test : Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently)
- - tor-hardening : Compile tor with hardening on vanilla compilers/linkers
- - zstd : Use app-arch/zstd for compression
gentoo bug : bugs.gentoo.org/669510
**Trac**:
**Username**: n05Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28081rust protover discards all votes if one is not UTF-82020-06-13T15:32:56ZTracrust protover discards all votes if one is not UTF-8
**Trac**:
**Username**: cyberpunks
**Trac**:
**Username**: cyberpunksTor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6623--enable-static-tor cannot succeed2020-06-13T15:31:52ZTrac--enable-static-tor cannot succeedBuild environment: CentOS v5.8/x86_64 with GCC v4.4.6.
Use of the --enable-static-tor cannot result in a successful build, at least not with GLibC v2.5.
Use of this flag causes the --static switch to be placed on the compiler command l...Build environment: CentOS v5.8/x86_64 with GCC v4.4.6.
Use of the --enable-static-tor cannot result in a successful build, at least not with GLibC v2.5.
Use of this flag causes the --static switch to be placed on the compiler command line when running tests from the configure script. So when the script tries to verify, say, a working libevent library, the test fails. Then the script falsely believes that the intended test (e.g. finding a linkable libevent lib) has failed. The actual failure is the inability to staticly link GLibC.
Here's as example:
$ gcc44 -o /tmp/conftest -static -I/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/include -I${top_srcdir}/src/common -L/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib -L/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib /tmp/conftest.c -lpthread -ldl -lrt -levent
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libevent.a(evutil.o): In function `test_for_getaddrinfo_hacks':
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/libevent-2.0.19-stable/evutil.c:1105: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libevent.a(evutil.o): In function `evutil_unparse_protoname':
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/libevent-2.0.19-stable/evutil.c:758: warning: Using 'getprotobynumber' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libevent.a(event.o): In function `gettime':
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/libevent-2.0.19-stable/event.c:366: undefined reference to `clock_gettime'
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libevent.a(event.o): In function `detect_monotonic':
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/libevent-2.0.19-stable/event.c:336: undefined reference to `clock_gettime'
Ouch! Guess it couldn't find a working libevent.a, right? Wrong!
What linker couldn't do is staticly link GLibC's runtime libraries. Remove that --static from the command line and the configure script's test succeeds in linking against the specified static libevent library.
Tor can be successfully linked against static zlib/openssl/libevent libraries but it cannot be staticly linked against gLibC. This makes --enable-static-tor pointless, a least for Linux builds.
**Trac**:
**Username**: tmpname0901Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27802OpenSSL 1.1.0 issue during static link2020-06-13T15:31:52ZTracOpenSSL 1.1.0 issue during static linkHere's my configure call (using Tor 0.3.5.1-alpha in my case):
```
sh ./configure --prefix=/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/dist --disable-gcc-hardening --disable-system-torrc --disable-asciidoc --enable-...Here's my configure call (using Tor 0.3.5.1-alpha in my case):
```
sh ./configure --prefix=/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/dist --disable-gcc-hardening --disable-system-torrc --disable-asciidoc --enable-static-libevent --with-libevent-dir=/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../libevent/dist --enable-static-openssl --with-openssl-dir=/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist --enable-static-zlib --with-zlib-dir=/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist --enable-static-tor
```
Note, this all works fine with OpenSSL 1.0.x. Running gets:
```
configure: Now, we'll look for OpenSSL >= 1.0.1
checking for openssl directory... configure: WARNING: Could not find a linkable openssl. If you have it installed somewhere unusual, you can specify an explicit path using --with-openssl-dir
configure: WARNING: On Debian, you can install openssl using "apt-get install libssl-dev"
configure: error: Missing libraries; unable to proceed.
```
Looking in config.log where it's checking OpenSSL:
```
configure:9656: Now, we'll look for OpenSSL >= 1.0.1
configure:9677: checking for openssl directory
configure:9732: gcc -o conftest -g -O2 -static -I/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist/include -L/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist/lib conftest.c -lpthread -ldl -lssl -lcrypto >&5
/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist/lib/libcrypto.a(b_addr.o): In function `BIO_lookup':
b_addr.c:(.text+0xc9c): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist/lib/libcrypto.a(b_sock.o): In function `BIO_gethostbyname':
b_sock.c:(.text+0x71): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function `CRYPTO_THREAD_lock_new':
threads_pthread.c:(.text+0x25): undefined reference to `pthread_rwlock_init'
/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function `CRYPTO_THREAD_read_lock':
threads_pthread.c:(.text+0x65): undefined reference to `pthread_rwlock_rdlock'
/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function `CRYPTO_THREAD_write_lock':
threads_pthread.c:(.text+0x85): undefined reference to `pthread_rwlock_wrlock'
/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function `CRYPTO_THREAD_unlock':
threads_pthread.c:(.text+0xa5): undefined reference to `pthread_rwlock_unlock'
/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function `CRYPTO_THREAD_lock_free':
threads_pthread.c:(.text+0xca): undefined reference to `pthread_rwlock_destroy'
/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function `CRYPTO_THREAD_run_once':
threads_pthread.c:(.text+0xf5): undefined reference to `pthread_once'
/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function `CRYPTO_THREAD_init_local':
threads_pthread.c:(.text+0x115): undefined reference to `pthread_key_create'
/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function `CRYPTO_THREAD_set_local':
threads_pthread.c:(.text+0x147): undefined reference to `pthread_setspecific'
/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function `CRYPTO_THREAD_cleanup_local':
threads_pthread.c:(.text+0x167): undefined reference to `pthread_key_delete'
/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function `CRYPTO_THREAD_get_local':
threads_pthread.c:(.text+0x133): undefined reference to `pthread_getspecific'
/home/cretz/work/bine/gopath/src/github.com/cretz/tor-static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function `CRYPTO_THREAD_get_current_id':
threads_pthread.c:(.text+0x181): undefined reference to `pthread_self'
/usr/lib/gcc/x86_64-linux-gnu/5/libgcc_eh.a(unwind-dw2.o): In function `uw_init_context_1':
(.text+0x1e0d): undefined reference to `pthread_once'
collect2: error: ld returned 1 exit status
```
And also:
```
configure:9732: gcc -o conftest -g -O2 -static conftest.c -lpthread -ldl -lssl -lcrypto >&5
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup':
(.text+0x11): undefined reference to `dlopen'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup':
(.text+0x24): undefined reference to `dlsym'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup':
(.text+0x2f): undefined reference to `dlclose'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func':
(.text+0x334): undefined reference to `dlsym'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func':
(.text+0x3db): undefined reference to `dlerror'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var':
(.text+0x454): undefined reference to `dlsym'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var':
(.text+0x4fb): undefined reference to `dlerror'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
(.text+0x569): undefined reference to `dlopen'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
(.text+0x5cb): undefined reference to `dlclose'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
(.text+0x603): undefined reference to `dlerror'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr':
(.text+0x69f): undefined reference to `dladdr'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr':
(.text+0x709): undefined reference to `dlerror'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload':
(.text+0x762): undefined reference to `dlclose'
collect2: error: ld returned 1 exit status
```
This is happening because the gcc call is putting -lssl and -lcrypto after -lpthread and -ldl instead of before it. This apparently has been happening a long time (see #12720) and I can't find any recent blame to cause this. I have also confirmed this is happening in Windows using MinGW on static builds too.
Please adjust TOR_SEARCH_LIBRARY or whatever is needed to make sure the -lssl and -lcrypto appear first on these checks. In the meantime, devs can solve this by setting the LIBS env var to "-lssl -lcrypto -lcrypt32 -lgdi32 -lws2_32" at least on Windows and presumably "-lssl -lcrypto -lpthread -ldl" on Linux (running into #6623 on Linux, so unsure).
**Trac**:
**Username**: cretzTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27722rust protover doesn't canonicalize adjacent and overlapping ranges2020-06-13T15:31:26ZTracrust protover doesn't canonicalize adjacent and overlapping ranges`protover.c` accepts both `"Foo=1-3,4-5"` and `"Foo=1-3,2-5"` and then canonicalizes them into `"Foo=1-5"` with `contract_protocol_list()`. Rust rejects the 2nd one as malformed.
**Trac**:
**Username**: cyberpunks`protover.c` accepts both `"Foo=1-3,4-5"` and `"Foo=1-3,2-5"` and then canonicalizes them into `"Foo=1-5"` with `contract_protocol_list()`. Rust rejects the 2nd one as malformed.
**Trac**:
**Username**: cyberpunksTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27201rust/protover doesn't forbid version zero2020-06-13T15:29:39ZTracrust/protover doesn't forbid version zeroPer the spec, version integers can't begin with, or be, zero:
```
Int = NON_ZERO_DIGIT
Int = Int DIGIT
```
**Trac**:
**Username**: cyberpunksPer the spec, version integers can't begin with, or be, zero:
```
Int = NON_ZERO_DIGIT
Int = Int DIGIT
```
**Trac**:
**Username**: cyberpunksTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27194Reject protover extra commas in protover2020-06-13T15:29:36ZTracReject protover extra commas in protoverLike how it handles spaces, `protover.c` rejects leading commas (`Link=,1-5` or `Link=,`) while it accepts and ignores extra commas elsewhere (`Link=1-5,` and `Link=1,,,2-5` are valid).
The Rust version accepts and ignores all extra com...Like how it handles spaces, `protover.c` rejects leading commas (`Link=,1-5` or `Link=,`) while it accepts and ignores extra commas elsewhere (`Link=1-5,` and `Link=1,,,2-5` are valid).
The Rust version accepts and ignores all extra commas, including leading commas.
**Trac**:
**Username**: cyberpunksTor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/27191handling double spaces in protover2020-06-13T15:29:34ZTrachandling double spaces in protover`protover.c` accepts trailing spaces and extra spaces between subprotocol entries like `"Link=1-4 LinkAuth=1 "`, but rejects leading spaces like `" Link=1-4"`. It has since its [introduction.](https://gitweb.torproject.org/tor.git/commi...`protover.c` accepts trailing spaces and extra spaces between subprotocol entries like `"Link=1-4 LinkAuth=1 "`, but rejects leading spaces like `" Link=1-4"`. It has since its [introduction.](https://gitweb.torproject.org/tor.git/commit/?id=b2b2e1c7f24d9b65059e3d089768d6c49ba4f58f)
The Rust implementation rejects all extra spaces in any position. It's at least consistent.
**Trac**:
**Username**: cyberpunksTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27190disparate duplicate subproto handling in protover2020-06-13T15:29:33ZTracdisparate duplicate subproto handling in protover`protover.c` treats `Link=1 Link=1` and `Link=1` identically, allowing duplicate entries without complaint, though it does explicitly check for duplicates to avoid double-counting it as two votes for the same version.
`protover.c` also ...`protover.c` treats `Link=1 Link=1` and `Link=1` identically, allowing duplicate entries without complaint, though it does explicitly check for duplicates to avoid double-counting it as two votes for the same version.
`protover.c` also treats `Link=1 Link=2` and `Link=1-2` the same, while the rust implementation of protover treats `Link=1 Link=2` as if it were `Link=2`.
**Trac**:
**Username**: cyberpunksTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27130rust dependency updating instructions don't work2020-06-13T15:29:20ZTracrust dependency updating instructions don't workNone of the instructions mention updating `Cargo.lock`, which is required. The script `updateRustDependencies.sh` doesn't update that file, either.
**Trac**:
**Username**: cyberpunksNone of the instructions mention updating `Cargo.lock`, which is required. The script `updateRustDependencies.sh` doesn't update that file, either.
**Trac**:
**Username**: cyberpunksTor: unspecifiedNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/27066circuit_build_times_update_alpha(): Bug: Could not determine largest build time2020-06-13T15:29:07ZTraccircuit_build_times_update_alpha(): Bug: Could not determine largest build timeThis bug occurs only when v3 hidden services are activated (4 hours after activation v3 services). This was my second test of v3 services and this issue repeated again. Server was running aprox.150 v3 domains.
After below warnings, all ...This bug occurs only when v3 hidden services are activated (4 hours after activation v3 services). This was my second test of v3 services and this issue repeated again. Server was running aprox.150 v3 domains.
After below warnings, all hidden services stoped working.
Could be related to #25733.
```
Aug 07 04:45:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 7525ms and we've abandoned 996 out of 1000 circuits. (on Tor 0.3.3.9 )
Aug 07 04:45:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 7525ms and we've abandoned 997 out of 1000 circuits. (on Tor 0.3.3.9 )
Aug 07 04:45:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 7525ms and we've abandoned 998 out of 1000 circuits. (on Tor 0.3.3.9 )
Aug 07 04:45:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 7525ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.3.9 )
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
...........
```
**Trac**:
**Username**: cstestTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27049"No circuits are opened" messages with onion services2020-06-13T15:29:03ZMike Perry"No circuits are opened" messages with onion servicesIf a Tor instance is only doing onion service activity, and circuits time out, then the Tor client thinks that circuits aren't opened and gives them a full minute to complete. It also complains about this in the logs at notice level, lik...If a Tor instance is only doing onion service activity, and circuits time out, then the Tor client thinks that circuits aren't opened and gives them a full minute to complete. It also complains about this in the logs at notice level, like this:
```
Aug 06 02:55:30.000 [notice] No circuits are opened. Relaxed timeout for circuit 21570 (a Hidden service: Pre-built vanguard circuit 4-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway.
```
The fix is simple. circuit_any_opened_circuits() in circuitlist.c is only counting circuits as opened if they use the DEFAULT_ROUTE_LEN. We just need to count >= DEFAULT_ROUTE_LEN to count them.Tor: unspecifiedMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/26787Core file left on travis hardened rust builld2020-06-13T15:28:01ZMike PerryCore file left on travis hardened rust builldhttps://travis-ci.org/torproject/tor/jobs/403730172
It looks like all the tests pass, the only problem I can see is the mysterious core left over at the end. I'm unable to get this to happen on my system.https://travis-ci.org/torproject/tor/jobs/403730172
It looks like all the tests pass, the only problem I can see is the mysterious core left over at the end. I'm unable to get this to happen on my system.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26469tor on SunOS: [err] Error from libevent: evport.c:425: Assertion evpd->ed_pen...2020-06-13T15:27:02ZTractor on SunOS: [err] Error from libevent: evport.c:425: Assertion evpd->ed_pending[i] == fd failed in evport_del
```
Tor 0.3.3.7 (git-035a35178c92da94) running on SunOS with Libevent 2.1.8-stable, OpenSSL 1.0.2o, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
```
(this error was also observed under tor 0.3.3.6 for about two weeks, no change with updat...
```
Tor 0.3.3.7 (git-035a35178c92da94) running on SunOS with Libevent 2.1.8-stable, OpenSSL 1.0.2o, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
```
(this error was also observed under tor 0.3.3.6 for about two weeks, no change with updating to 0.3.3.7)
every 10-20 minutes (sometimes longer) the process crashes with:
```
[err] Error from libevent: evport.c:425: Assertion evpd->ed_pending[i] == fd failed in evport_del
```
Contrary to tor crashes no libevent stacktrace is provided in default output.
The OS-Project under which the Service is running should have sufficent fd-ulimits:
```
ulimit -n
65536
```
Service privileges for the running User are pretty standard:
```
privileges='basic,net_privaddr'
```
**Trac**:
**Username**: ruebezahlTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26356Tor 0.3.3.6 fails to compile under cygwin (x86_64)2020-06-13T15:26:35ZGeorg KoppenTor 0.3.3.6 fails to compile under cygwin (x86_64)From the 0.3.3.6 blog post's comments (https://blog.torproject.org/comment/275501#comment-275501):
```
I try to build latest tor 0.3.3.6 from source under "x86_64 Cygwin".
Earlier versions did compile, I'm running now "Tor version 0.3.2....From the 0.3.3.6 blog post's comments (https://blog.torproject.org/comment/275501#comment-275501):
```
I try to build latest tor 0.3.3.6 from source under "x86_64 Cygwin".
Earlier versions did compile, I'm running now "Tor version 0.3.2.9 (git-9e8b762fcecfece6)."
Compilation now Fails with the following erros:
make all-am
make[1]: Entering directory '/cygdrive/f/tor-0.3.3.6'
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_0.o
In file included from src/ext/ed25519/ref10/crypto_int32.h:6,
from src/ext/ed25519/ref10/fe.h:4,
from src/ext/ed25519/ref10/fe_0.c:1:
./src/common/torint.h:214:2: error: #error "Can't define ssize_t."
#error "Can't define ssize_t."
^~~~~
./src/common/torint.h:237:2: error: #error "void * is either >8 bytes or <= 2. In either case, I am confused."
#error "void * is either >8 bytes or <= 2. In either case, I am confused."
^~~~~
./src/common/torint.h:241:2: error: #error "Missing type int8_t"
#error "Missing type int8_t"
^~~~~
./src/common/torint.h:244:2: error: #error "Missing type uint8_t"
#error "Missing type uint8_t"
^~~~~
./src/common/torint.h:247:2: error: #error "Missing type int16_t"
#error "Missing type int16_t"
^~~~~
./src/common/torint.h:250:2: error: #error "Missing type uint16_t"
#error "Missing type uint16_t"
^~~~~
./src/common/torint.h:253:2: error: #error "Missing type int32_t"
#error "Missing type int32_t"
^~~~~
./src/common/torint.h:256:2: error: #error "Missing type uint32_t"
#error "Missing type uint32_t"
^~~~~
./src/common/torint.h:259:2: error: #error "Missing type int64_t"
#error "Missing type int64_t"
^~~~~
./src/common/torint.h:262:2: error: #error "Missing type uint64_t"
#error "Missing type uint64_t"
^~~~~
./src/common/torint.h:269:2: error: #error "Seems that your platform doesn't use 2's complement arithmetic. Argh."
#error "Seems that your platform doesn't use 2's complement arithmetic. Argh."
^~~~~
./src/common/torint.h:277:2: error: #error "Can't define LONG_MAX"
#error "Can't define LONG_MAX"
^~~~~
./src/common/torint.h:287:2: error: #error "Can't define INT_MAX"
#error "Can't define INT_MAX"
^~~~~
./src/common/torint.h:299:2: error: #error "Can't define UINT_MAX"
#error "Can't define UINT_MAX"
^~~~~
./src/common/torint.h:309:2: error: #error "Can't define SHORT_MAX"
#error "Can't define SHORT_MAX"
^~~~~
./src/common/torint.h:367:2: error: #error "Can't define SSIZE_MAX"
#error "Can't define SSIZE_MAX"
^~~~~
make[1]: *** [Makefile:6513: src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_0.o] Error 1
make[1]: Leaving directory '/cygdrive/f/tor-0.3.3.6'
make: *** [Makefile:3409: all] Error 2
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25386Link Rust Tests to C Dependencies in Tor (allow integration testing from Rust...2020-06-13T15:26:10ZAlex XuLink Rust Tests to C Dependencies in Tor (allow integration testing from Rust to C)currently, it is not possible to call C Tor, directly or indirectly, from rust tests. one of the following must be done:
1. provide rust stubs for all C functions that may be needed for tests (impractical)
2. test rust functions from C...currently, it is not possible to call C Tor, directly or indirectly, from rust tests. one of the following must be done:
1. provide rust stubs for all C functions that may be needed for tests (impractical)
2. test rust functions from C (so we will have C tests calling Rust functions calling C functions)
3. link C functions into rust doctests (preferred)
4. never call C-using rust functions in tests (leads to poor test coverage, very bad)
my branch https://cgit.alxu.ca/tor.git/commit/?h=fix-rust-tests implements option 3 poorly. this is a bad solution firstly because it is very ugly, and secondly because it does not properly pass the system linking arguments, e.g. -L/opt/ssl. thirdly, it may hide problems in or cause to be compiled incorrectly dependency crates.
this ticket blocks a number of rust improvements, since of course we would like to actually test the improvements, and doctests are the best way to do it in rust.Tor: unspecified