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>

Unreviewed build fix. Discussed the cnage on IRC with Nick.

This was a bad copy and paste error from the previous commit which
generated a duplicated entry error from practracker.

Unreviewed build fix.

See: tor#40275.

We solve this error by allowing the connection_exit_connect() function
to be 130 lines long.

Unreviewed build fix commit.

See: tor#40275.

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

"ours" to avoid version bump.

"ours" to avoid version bump.

Signed-off-by: David Goulet <dgoulet@torproject.org>

Any lookup now will be certain and not probabilistic as the bloomfilter.

Closes #40269

Signed-off-by: David Goulet <dgoulet@torproject.org>

The TORPROTOCOL reason causes the client to close the circuit which is not
what we want because other valid streams might be on it.

Instead, CONNECTION_REFUSED will leave it open but will not allow more streams
to be attached to it. The client then open a new circuit to the destination.

Closes #40270

Signed-off-by: David Goulet <dgoulet@torproject.org>

This is to minimize false positive and thus deny reentry to Exit connections
that were in reality not re-entering. Helps with overall UX.

Signed-off-by: David Goulet <dgoulet@torproject.org>

Obey the "allow-network-reentry" consensus parameters in order to decide to
allow it or not at the Exit.

Closes #40268

Signed-off-by: David Goulet <dgoulet@torproject.org>

George Kadianakis authored 4 years ago and David Goulet committed 4 years ago

Signed-off-by: David Goulet <dgoulet@torproject.org>

Roger Dingledine authored 4 years ago and David Goulet committed 4 years ago

Exit relays now reject exit attempts to known relay addresses + ORPort and
also to authorities on the ORPort and DirPort.

Closes #2667

Signed-off-by: David Goulet <dgoulet@torproject.org>

In order to deny re-entry in the network, we now keep a bloomfilter of relay
ORPort + address and authorities ORPort + address and DirPort + address
combinations.

So when an Exit stream is handled, we deny anything connecting back into the
network on the ORPorts for relays and on the ORPort+DirPort for the
authorities.

Related to #2667

Signed-off-by: David Goulet <dgoulet@torproject.org>