Nick Mathewson [Sat, 6 Nov 2021 15:04:08 +0000 (11:04 -0400)]
Give an error message if LibreSSL's TLSv1.3 APIs aren't what we need
From LibreSSL versions 3.2.1 through 3.4.0, our configure script
would conclude that TLSv1.3 as supported, but it actually wasn't.
This led to annoying breakage like #40128 and #40445.
Now we give an error message if we try to build with one of those
versions.
Nick Mathewson [Fri, 5 Nov 2021 17:23:05 +0000 (13:23 -0400)]
Reverse the direction of the test for openssl 3.0.0
Previously the logic was reversed, and always gave the wrong answer.
This has no other effect than to change whether we suppress
deprecated API warnings.
Nick Mathewson [Fri, 5 Nov 2021 16:08:48 +0000 (12:08 -0400)]
Prefer use of __MINGW_PRINTF/SCANF_FORMAT if available.
Mingw headers sometimes like to define alternative scanf/printf
format attributes depending on whether they're using clang, UCRT,
MINGW_ANSI_STDIO, or the microsoft version of printf/scanf. This
change attempts to use the right one on the given platform.
Simon South [Fri, 5 Nov 2021 14:10:10 +0000 (10:10 -0400)]
sandbox: Allow "statx" syscall on i386 for glibc 2.33
glibc versions 2.33 and newer use the modern "statx" system call in their
implementations of stat() and opendir() for Linux on i386. Prevent failures in
the sandbox unit tests by modifying the sandbox to allow this system call
without restriction on i386 when it is available, and update the test suite to
skip the "sandbox/stat_filename" test in this case as it is certain to fail.
Simon South [Wed, 3 Nov 2021 16:21:35 +0000 (12:21 -0400)]
test: Skip sandbox/stat_filename where "stat64" syscall defined
On 32-bit architectures where Linux provides the "stat64" system call,
including i386, the sandbox is unable to filter calls to stat() as glibc uses
this system call itself internally and the sandbox must allow it without
restriction.
Update the sandbox unit tests to skip the "sandbox/stat_filename" test on
systems where the "stat64" system call is defined and the test is certain to
fail. Also reorder the "#if" statement's clauses to correspond with the
comment preceding it, for clarity.
Simon South [Wed, 3 Nov 2021 15:53:33 +0000 (11:53 -0400)]
sandbox: Allow "clock_gettime64" syscall where defined
On 32-bit architectures where Linux provides the "clock_gettime64" system call,
including i386, glibc uses it in place of "clock_gettime". Modify the sandbox
implementation to match, to prevent Tor's monotonic-time functions (in
src/lib/time/compat_time.c) failing when the sandbox is active.
Simon South [Wed, 3 Nov 2021 14:48:16 +0000 (10:48 -0400)]
sandbox: Filter "chown32" syscall on i386
On i386 glibc uses the "chown32" system call instead of "chown". Prevent
attempts to filter calls to chown() on this architecture from failing by
modifying the sandbox implementation to match.
David Goulet [Fri, 5 Nov 2021 14:10:24 +0000 (10:10 -0400)]
protover: Move all hardcoded lists in one place
This also moves the warnings and add some theatrical effect around the
code so anyone modifying those list should notice the warnings signs and
read the comment accordingly.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Alexander Færøy [Fri, 5 Feb 2021 17:12:52 +0000 (17:12 +0000)]
Fix Windows build.
While trying to resolve our CI issues, the Windows build broke with an
unused function error:
src/test/test_switch_id.c:37:1: error: ‘unprivileged_port_range_start’
defined but not used [-Werror=unused-function]
We solve this by moving the `#if !defined(_WIN32)` test above the
`unprivileged_port_range_start()` function defintion such that it is
included in its body.
Roger Dingledine [Sun, 24 Oct 2021 00:32:36 +0000 (20:32 -0400)]
don't retry entry guards if they're bridges without descriptors
When we don't yet have a descriptor for one of our bridges, disable
the entry guard retry schedule on that bridge. The entry guard retry
schedule and the bridge descriptor retry schedule can conflict,
e.g. where we mark a bridge as "maybe up" yet we don't try to fetch
its descriptor yet, leading Tor to wait (refusing to do anything)
until it becomes time to fetch the descriptor.
Roger Dingledine [Sat, 23 Oct 2021 09:24:29 +0000 (05:24 -0400)]
do notice-level log when we resume having enough dir info
we do a notice-level log when we decide we *don't* have enough dir
info, but in 0.3.5.1-alpha (see commit eee62e13d97, #14950) we lost our
corresponding notice-level log when things come back.
Roger Dingledine [Fri, 29 Oct 2021 00:39:31 +0000 (20:39 -0400)]
handle other de-sync cases from #40396
Specifically, every time a guard moves into or out of state
GUARD_REACHABLE_MAYBE, it is an opportunity for the guard reachability
state to get out of sync with the have-minimum-dir-info state.
Roger Dingledine [Fri, 22 Oct 2021 06:33:49 +0000 (02:33 -0400)]
reassess minimum-dir-info when a bridge fails
When we try to fetch a bridge descriptor and we fail, we mark
the guard as failed, but we never scheduled a re-compute for
router_have_minimum_dir_info().
So if we had already decided we needed to wait for this new descriptor,
we would just wait forever -- even if, counterintuitively, *losing* the
bridge is just what we need to *resume* using the network, if we had it
in state GUARD_REACHABLE_MAYBE and we were stalling to learn this outcome.
Roger Dingledine [Fri, 29 Oct 2021 00:53:26 +0000 (20:53 -0400)]
only log "new bridge descriptor" if really new
The bridge descriptor fetching codes ends up fetching a lot of duplicate
bridge descriptors, because this is how we learn when the descriptor
changes.
This commit only changes comments plus whether we log that one line.
It moves us back to the old behavior, before the previous commit for
30496, where we would only log that line when the bridge descriptor
we're talking about is better than the one we already had (if any).
projects / thirdparty / tor.git / log
