GitLab

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

This patch ensures that we return TOR_COMPRESS_BUFFER_FULL in case we
have a input bytes left to process, but are out of output buffer or in
case we need to finish where the compression implementation might need
to write an epilogue.

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

These tests try uncompressing garbage, verify that we won't
make compression bombs, and verify that we won't uncompress
compression bombs.

Apparently, my compiler now generates coverage markers for
label-only lines, so we need to exclude those too if they are meant
to be unreachable.

There was some coverage before, but it was mostly accidental.

Coverage is now respectable. :)

We use these when we're acting as a SOCKS client, but we'd never
actually written tests for them :/

These tests aren't reachable, given their actual arguments.  I'm
going to mark them as BUG(), and as unreachable with LCOV.

Many of the 'truncated command' paths in fetch_from_buf_socks() were
not reached by the tests.  This new unit test tries to check them
exhaustively.

No other code changes.

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

The confparse field has type UINT, which corresponds to an int
type.  We had uint32_t.

This shouldn't cause trouble in practice, since int happens to
4-bytes wide on every platform where an authority is running.  It's
still wrong, though.

The correct type for a STRING confparse value is char *, not const
char *.

These should have been int, but we had listed them as unsigned.
That's an easy mistake to make, since "int" corresponds with either
INT or UINT in the configuration file.

This bug cannot have actually caused a problem in practice, since we
check those fields' values on load, and ensure that they are in
range 0..INT32_MAX.

New approach, suggested by Taylor: During testing builds, we
initialize a union member of an appropriate pointer type with the
address of the member field we're trying to test, so we can make
sure that the compiler doesn't warn.

My earlier approach invoked undefined behavior.

Also demote a log message that can occur under natural causes
(if the circuit subsystem is missing descriptors/consensus etc.).
The HS subsystem will naturally retry to connect to intro points,
so no need to make that log user-facing.

So we can track them more easily in the logs and match any open/close/free
with those identifiers.

Part of #23645
Signed-off-by: David Goulet <dgoulet@torproject.org>

This removes the "nickname" of the cannibalized circuit last hop as it is
useless. It now logs the n_circ_id and global identifier so we can match it
with other logging statement.
Signed-off-by: David Goulet <dgoulet@torproject.org>

Prior to the log statement, the circuit n_circ_id value is zeroed so keep a
copy so we can log it at the end.

Part of #23645
Signed-off-by: David Goulet <dgoulet@torproject.org>

Part of #23645
Signed-off-by: David Goulet <dgoulet@torproject.org>