Age | Commit message (Collapse) | Author |
|
|
|
tl;dr We were not counting cells flying from the client to the service, but we
were counting cells flying from the service to the client.
When a rendezvous cell arrives from the client to the RP, the RP forwards it to
the service.
For this to happen, the cell first passes through command_process_relay_cell()
which normally does the statistics counting. However because the `rend_circ`
circuit was not flagged with `circuit_carries_hs_traffic_stats` in
rend_mid_rendezvous(), the cell is not counted there.
Then the cell goes to circuit_receive_relay_cell() which has a special code
block based on `rend_splice` specifically for rendezvous cells, and the cell
gets directly passed to `rend_circ` via a direct call to
circuit_receive_relay_cell(). The cell never passes through
command_process_relay_cell() ever again and hence is never counted by our
rephist module.
The fix here is to flag the `rend_circ` circuit with
`circuit_carries_hs_traffic_stats` so that the cell is counted as soon as it
hits command_process_relay_cell().
Furthermore we avoid double-counting cells since the special code block of
circuit_receive_relay_cell() makes us count rendezvous cells only as they enter
the RP and not as they exit it.
Fixes #40117.
|
|
Fixes #40105.
|
|
|
|
|
|
Turns out that the HS DoS defenses parameters were overwritten by the
consensus parameters everytime a new consensus would arrive.
This means that a service operator can still enable the defenses but as soon
as the intro point relay would get a new consensus, they would be overwritten.
And at this commit, the network is entirely disabling DoS defenses.
Fix this by introducing an "explicit" flag that indicate if the
ESTABLISH_INTRO cell DoS extension set those parameters or not. If set, avoid
using the consenus at once.
We are not bumping the protover HSIntro value for this because 0.4.2.x series
is EOL in 1 month and thus 0.4.3.x would be the only series with this bug. We
are confident that a backport and then upgrade path to the latest 0.4.4.x
stable coming up soon is enough to mitigate this problem in the coming months.
It avoids the upgrade path on the service side by keeping the requirement for
protover HSIntro=5.
Fixes #40109
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Without this fix, running this test on its own would fail.
Fixes bug 40099. Bugfix on ade5005853c17b3 in 0.2.8.1-alpha.
|
|
|
|
|
|
|
|
For clients, there is no minimum value; in both cases, we warn if
the value seems too low.
Closes ticket 24308.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes conflicts due to code movement.
|
|
This fixes bug 40083, which was introduced in 9f31908a in
0.2.8.1-alpha.
|
|
Resolves conflicts:
src/core/or/channel.c
src/test/test_channel.c
|
|
This function once served to let circuits continue to be built over
version-1 link connections. But such connections are long-obsolete,
and it's time to remove this check.
Closes #40081.
|
|
This is a defense-in-depth fix; closes 6198.
|
|
Frequently we want to do
if (s) {
memwipe(s, 0, sizeof(s));
tor_free(s);
}
and it's good to have a way to do this concisely.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We found this in #40076, after we started using buf_move_all() in
more places. Fixes bug #40076; bugfix on 0.3.3.1-alpha. As far as
I know, the crash only affects master, but I think this warrants a
backport, "just in case".
|
|
The failing case is #if'd out for now, but will be fixed in the next
commit.
Testing for a fix for #40076.
|
|
|
|
|
|
|
|
|
|
Fix crash introduced in #40020. On startup, tor calls
check_private_dir on the data and key directories. This function
uses open instead of opendir on the received directory. Data and
key directoryes are only opened here, so the seccomp rule added
should be for open instead of opendir, despite the fact that they
are directories.
|
|
Fixes bug 31036; bugfix on 0.2.1.8-alpha when we moved the logging
system to use posix fds.
|
|
|
|
|
|
|
|
|