| Age | Commit message (Collapse) | Author |
|---|
|
|
|
It was used nowhere outside its own unit tests, and it was causing
compilation issues with recent OpenSSL 3.0.0 alphas.
Closes ticket 40399.
|
|
This is a bugfix against my fix for #40133, which has not yet
appeared in 0.3.5.
|
|
Now deprecated in libc >= 2.33
Closes #40309
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Now deprecated in libc >= 2.33
Closes #40309
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
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.
This is an unreviewed commit.
See: tor#40275
|
|
|
|
We currently assume that the only way for Tor to listen on ports in the
privileged port range (1 to 1023), on Linux, is if we are granted the
NET_BIND_SERVICE capability. Today on Linux, it's possible to specify
the beginning of the unprivileged port range using a sysctl
configuration option. Docker (and thus the CI service Tor uses) recently
changed this sysctl value to 0, which causes our tests to fail as they
assume that we should NOT be able to bind to a privileged port *without*
the NET_BIND_SERVICE capability.
In this patch, we read the value of the sysctl value via the /proc/sys/
filesystem iff it's present, otherwise we assume the default
unprivileged port range begins at port 1024.
See: tor#40275
|
|
|
|
|
|
Any lookup now will be certain and not probabilistic as the bloomfilter.
Closes #40269
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Some days before this commit, the network experienced a DDoS on the directory
authorities that prevented them to generate a consensus for more than 5 hours
straight.
That in turn entirely disabled onion service v3, client and service side, due
to the subsystem requiring a live consensus to function properly.
We know require a reasonably live consensus which means that the HSv3
subsystem will to its job for using the best consensus tor can find. If the
entire network is using an old consensus, than this should be alright.
If the service happens to use a live consensus while a client is not, it
should still work because the client will use the current SRV it sees which
might be the previous SRV for the service for which it still publish
descriptors for.
If the service is using an old one and somehow can't get a new one while
clients are on a new one, then reachability issues might arise. However, this
is a situation we already have at the moment since the service will simply not
work if it doesn't have a live consensus while a client has one.
Fixes #40237
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
|
|
We can use our existing mocking functionality to do this: We have
been in this position before.
Fixes part of #40179; bugfix on 0.4.3.1-alpha.
|
|
Previously, hashlib.shake_256 was a class (if present); now it can
also be a function. This change invalidated our old
compatibility/workaround code, and made one of our tests fail.
Fixes bug 40179; bugfix on 0.3.1.6-rc when the workaround code was
added.
|
|
|
|
|
|
OpenSSL doesn't seem to report error locations in the same way as
before, which broke one of our tests.
Fixes bug 40170; bugfix on 0.2.8.1-alpha.
|
|
In brief: we go through a lot of gymnastics to handle huge protover
numbers, but after years of development we're not even close to 10
for any of our current versions. We also have a convenient
workaround available in case we ever run out of protocols: if (for
example) we someday need Link=64, we can just add Link2=0 or
something.
This patch is a minimal patch to change tor's behavior; it doesn't
take advantage of the new restrictions.
Implements #40133 and proposal 318.
|
|
|
|
|
|
|
|
|
|
|
|
First, we introduce a flag to teach src/test/test to split its work
into chunks. Then we replace our invocation of src/test/test in our
"make check" target with a set of 8 scripts that invoke the first
8th of the tests, the second 8th, and so on.
This change makes our "make -kj4 check" target in our hardened
gitlab build more than twice as fast, since src/test/test was taking
the longest to finish.
Closes 40098.
|
|
|
|
|
|
|
|
|
|
|
