Newer versions of cargo recently removed the ability to understand the
`[root]` section of Cargo.lock files, which is particularly relevant when
either `cargo --frozen` and/or `cargo --locked` are specified, and the
failure/inability to download a new index will cause the whole build to fail
with "error: the lock file needs to be updated but --frozen was passed to
prevent this" (cf. https://github.com/rust-lang/cargo/issues/4563).

 * REMOVE `[root]` section from our top-level `Cargo.lock` file.
 * FIXES #24608: https://bugs.torproject.org/24608

This commit was made mechanically by this perl script:

\#!/usr/bin/perl -w -i -p

next if /^#define FREE_AND_NULL/;
s/\bFREE_AND_NULL\((\w+),/FREE_AND_NULL\(${1}_t, ${1}_free_,/;
s/\bFREE_AND_NULL_UNMATCHED\(/FREE_AND_NULL\(/;

This commit removes the old FREE_AND_NULL, and renames the old
FREE_AND_NULL_UNMATCHED so that it is now called FREE_AND_NULL.

This will break all the FREE_AND_NULL_* users; the next commit will
fix them.

This one only evaluates the input once, so it cannot mess up even if
there are side effects.

This covers addressmap.h (no change needed) through confparse.h

David Goulet authored 7 years ago and Nick Mathewson committed 7 years ago

Closes #23709

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

David Goulet authored 7 years ago and Nick Mathewson committed 7 years ago

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

David Goulet authored 7 years ago and Nick Mathewson committed 7 years ago

Couple things happen in this commit. First, we do not re-queue a cell back in
the circuit queue if the write packed cell failed. Currently, it is close to
impossible to have it failed but just in case, the channel is mark as closed
and we move on.

The second thing is that the channel_write_packed_cell() always took ownership
of the cell whatever the outcome. This means, on success or failure, it needs
to free it.

It turns out that that we were using the wrong free function in one case and
not freeing it in an other possible code path. So, this commit makes sure we
only free it in one place that is at the very end of
channel_write_packed_cell() which is the top layer of the channel abstraction.
This makes also channel_tls_write_packed_cell_method() return a negative value
on error.

Two unit tests had to be fixed (quite trivial) due to a double free of the
packed cell in the test since now we do free it in all cases correctly.

Part of #23709

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

It looks like it was left behind in a refactor.

Fixes 24559.

Previously, circuit_stream_is_being_handled incorrectly reported
that (1) an exit port was "handled" by a circuit regardless of
whether the circuit was already isolated in some way, and
(2) that a stream could be "handled" by a circuit even if their
isolation settings were incompatible.

As a result of (1), in Tor Browser, circuit_get_unhandled_ports was
reporting that all ports were handled even though all non-internal
circuits had already been isolated by a SOCKS username+password.

Therefore, circuit_predict_and_launch_new was declining to launch
new exit circuits. Then, when the user visited a new site in Tor
Browser, a stream with new SOCKS credentials would be initiated,
and the stream would have to wait while a new circuit with those
credentials could be built. That wait was making the
time-to-first-byte longer than it needed to be.

Now, clean, not-yet-isolated circuit(s) will be automatically
launched ahead of time and be ready for use whenever a new stream
with new SOCKS credentials (or other isolation criteria) is
initiated.

Fixes bug 18859. Thanks to Nick Mathewson for improvements.

This makes sure that a non opened channel is never put back in the channel
pending list and that its state is consistent with what we expect that is
IDLE.

Test the fixes in #24502.

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

This patch adds a check for the return value of `hs_parse_address()` in
`hs_control_hspost_command()`. Since it should not be possible for
`hs_parse_address()` to fail in this context we wrap the error check
with the `BUG()` macro.

See: https://bugs.torproject.org/24543

Also, explain which files should be put in which.