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/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/25686Mystery bug causes relays to attempt many many descriptor publishes, with no ...2020-06-13T15:24:01ZRoger DingledineMystery bug causes relays to attempt many many descriptor publishes, with no X-Desc-Gen-Reason headerSometimes relays get into a state where they try to publish a new descriptor every second, and this state lasts for hours or days.
I instrumented moria1 to keep track of the X-Desc-Gen-Reason headers in each descriptor upload attempt:
`...Sometimes relays get into a state where they try to publish a new descriptor every second, and this state lasts for hours or days.
I instrumented moria1 to keep track of the X-Desc-Gen-Reason headers in each descriptor upload attempt:
```
diff --git a/src/or/directory.c b/src/or/directory.c
index c419b61..4570b20 100644
--- a/src/or/directory.c
+++ b/src/or/directory.c
@@ -5102,6 +5102,15 @@ directory_handle_command_post,(dir_connection_t *conn, const char *headers,
const char *msg = "[None]";
uint8_t purpose = authdir_mode_bridge(options) ?
ROUTER_PURPOSE_BRIDGE : ROUTER_PURPOSE_GENERAL;
+
+ {
+ char *genreason = http_get_header(headers, "X-Desc-Gen-Reason: ");
+ log_info(LD_DIRSERV,
+ "New descriptor post, because: %s",
+ genreason ? genreason : "not specified");
+ tor_free(genreason);
+ }
+
was_router_added_t r = dirserv_add_multiple_descriptors(body, purpose,
conn->base_.address, &msg);
tor_assert(msg);
```
And then I counted up the number of upload attempts of each type over the last two-ish weeks:
```
$ grep "New descriptor post, because:" moria1-info|cut -d: -f5-|sort|uniq -c
20685 bandwidth has changed
1 Chosen Or/DirPort changed
53191 config change
601 configured managed proxies
41663 DirPort found reachable
96 dns resolvers back
191 IP address changed
131619 not listed in consensus
1647625 not specified
31440 ORPort found reachable
8518 rotated onion key
28 set onion key
120487 time for new descriptor
156 Tor just started
25362 version listed in consensus is quite old
```
Now, the weird "not listed in consensus" and "version listed in consensus is quite old" ones are #25685.
But there are a huge number that are simply lacking this header. These tend to come from a relatively small number of relays that are just bombing me with publish attempts.
In fact, out of those 1647625 attempts that didn't provide a reason, nearly all of them got discarded:
```
$ grep -A1 "New descriptor post, because: not specified" moria1-info|grep "Not replacing descriptor"|wc -l
1645051
```
We should try to track down what bug on the relay side causes republishes without including a reason header. Maybe we do this by examining the code and looking for mistakes where a republish can happen without also setting the reason header?
See #3942 for a time long ago that we had problems with listing our reason. And see #21642 for where a lot of this analysis started.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25416[warn] Received http status code 404 ("Consensus is too old") from server '19...2020-06-13T15:22:44Ztoralf[warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.the local time is ok :
```
date -u
Sat Mar 3 16:18:01 UTC 2018
cat </dev/tcp/time.nist.gov/13
ntpdate -q 2.de.pool.ntp.org
server 2a01:4f8:172:326b::2, stratum 2, offset -0.000140, delay 0.02594
server 2a01:4f8:221:3b02::101:1, strat...the local time is ok :
```
date -u
Sat Mar 3 16:18:01 UTC 2018
cat </dev/tcp/time.nist.gov/13
ntpdate -q 2.de.pool.ntp.org
server 2a01:4f8:172:326b::2, stratum 2, offset -0.000140, delay 0.02594
server 2a01:4f8:221:3b02::101:1, stratum 2, offset -0.000601, delay 0.02594
server 2a01:238:439c:1900::3:1, stratum 2, offset 0.000477, delay 0.04520
server 2a02:16d0:0:4::4, stratum 2, offset -0.002245, delay 0.03976
server 90.187.7.5, stratum 2, offset -0.002271, delay 0.04788
server 129.70.132.36, stratum 2, offset 0.002152, delay 0.04262
server 145.239.3.131, stratum 2, offset 0.001487, delay 0.03177
server 85.236.36.4, stratum 2, offset -0.000501, delay 0.03650
3 Mar 17:18:09 ntpdate[18195]: adjust time server 2a01:4f8:221:3b02::101:1 offset -0.000601 sec
```
And I still get once a day or so _:
```
Mar 03 17:18:01.000 [warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.
Mar 03 17:18:01.000 [notice] Tor 0.3.4.0-alpha-dev (git-efc105716283bbdf) opening log file.
Mar 03 17:18:02.000 [warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.
```
tor version is 0.3.4-alpha-devTor: unspecified