Commit c3a0f75796 added this feature for ORPort
that we ignore any port that is not the family of our default address when
parsing the port. So if port_parse_config() was called with an IPv4 default
address, all IPv6 address would be ignored.
That makes sense for ORPort since we call twice port_parse_config() for
0.0.0.0 and [::] but for the rest of the ports, it is not good since a
perfectly valid configuration can be:
SocksPort 9050
SocksPort [::1]:9050
Any non-ORPort only binds by default to an IPv4 except the ORPort that binds
to both IPv4 and IPv6 by default.
The fix here is to always parse all ports within port_parse_config() and then,
specifically for ORPort, remove the duplicates or superseding ones. The
warning is only emitted when a port supersedes another.
A unit tests is added to make sure SocksPort of different family always exists
together.
Fixes#40183
Signed-off-by: David Goulet <dgoulet@torproject.org>
There were three separate places where we were hitting a sandbox Bug
warning before we actually exited.
Fixes#40094; bugfix on 0.3.1.1-alpha when %includes were introduced.
Typos found with codespell.
Please keep in mind that this should have impact on actual code
and must be carefully evaluated:
src/core/or/lttng_circuit.inc
- ctf_enum_value("CONTROLER", CIRCUIT_PURPOSE_CONTROLLER)
+ ctf_enum_value("CONTROLLER", CIRCUIT_PURPOSE_CONTROLLER)
We already did this, but we did it by accident, which is pretty
risky: if we hadn't, then our code would have treated extra data in
the inbuf as having been transmitted as TLS-authenticated data.
Closes ticket 40017; Found by opara.
This way, if we guess wrong about whether the library has it,
we don't conflict with the library's headers.
Fixes#40181; bug not in any released version.
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.
In the past, only authorities and clients had to use that function because of
the SRV subsystem. However, because of its use in rep_hist_hs_stats_init() it
will now also be used by relays when bootstrapping without a consensus. Make it
do something sensible.
Another approach (instead of using magic values) would be to wait
initialization of HSv3 stats until we get a consensus but that seems messy to
schedule.
Another approach would be to make dirauth_sched_get_configured_interval() also
work for relays (particularly when TestingNetwork is enabled), but that also
seems a good amount of work.
