Minor simplification and refactoring.
Make the dirauth tests focus on testing the intention of the code,
rather than option processing order.
Part of 32213.
The DoS heartbeat now contains the number of rejected INTRODUCE2 cell that the
relay has seen.
Closes#31371
Signed-off-by: David Goulet <dgoulet@torproject.org>
This required a small refactoring so we could count properly the INTRO2
sending disallow.
Part of #31371
Signed-off-by: David Goulet <dgoulet@torproject.org>
This commit:
* moves dirauth stats and mtbf config actions into dirauth_config,
* adds thin wrappers to make the moved code compile.
The moved code is disabled when the dirauth module is disabled.
Part of 32213.
This commit:
* moves relay config actions into relay_config,
* moves get_dirportfrontpage() into relay_config,
* adds thin wrappers to make the moved code compile.
No functional changes: the moved code is still enabled,
even if the relay module is disabled. (Some of the checks
are re-ordered, so the order of some warnings may change.)
Part of 32213.
This commit:
* moves server transport config checks into transport_config.c,
* adds thin wrappers to make the moved code compile.
No functional changes: the moved code is still enabled,
even if the relay module is disabled. (Some of the checks
are re-ordered, so the order of some warnings may change.)
Part of 32213.
This commit:
* moves bandwidth checks into dirauth_config, and
* moves some other minor checks into dirauth_config.
The moved code is disabled when the dirauth module is disabled.
(And some of the checks are re-ordered, so the order of some
warnings may change.)
Part of 32213.
This commit:
* moves accounting and bandwidth checks into relay_config,
* moves testing options checks into relay_config,
* moves some other minor checks into relay_config,
* exposes some code from src/app/config.c
(we'll refactor it later in 29211), and
* adds thin wrappers to make the moved code compile.
No functional changes: the moved code is still enabled,
even if the relay module is disabled. (Some of the checks
are re-ordered, so the order of some warnings may change.)
Part of 32213.
This commit:
* creates feature/relay/transport_config.[ch],
* moves server transport config checks into them,
* exposes some code from src/app/config.c
(we'll refactor it later in 29211), and
* adds thin wrappers to make the moved code compile.
No functional changes: the moved code is still enabled,
even if the relay module is disabled. (Some of the checks
are re-ordered, so the order of some warnings may change.)
Part of 32213.
This commit:
* moves relay config checks into relay_config.[ch],
* exposes some code from src/app/config.c
(we'll refactor it later in 29211), and
* adds thin wrappers to make the moved code compile.
No functional changes: the moved code is still enabled,
even if the relay module is disabled. (Some of the checks
are re-ordered, so the order of some warnings may change.)
Part of 32213.
This commit:
* creates feature/relay/relay_config.[ch],
* moves relay port parsing into them,
* exposes some code from src/app/config.c
(we'll refactor it later in 29211), and
* adds thin wrappers to make the moved code compile.
No functional changes: the moved code is still enabled,
even if the relay module is disabled.
Part of 32213.
This commit:
* creates feature/dirauth/dirauth_config.[ch],
* moves the dirauth config code into them,
* copies some macros from src/app/config.c
(we'll refactor them later in 29211), and
* adds thin wrappers to make the moved code compile.
No functional changes: the moved code is still enabled,
even if the dirauth module is disabled.
Part of 32213.
This will help us reimplement warn_about_relative_paths().
FILENAME options currently are the same as STRINGs in most respects,
except for the type reported to the controller.
In this commit, I'm picking the options to change based on:
* the current contents of warn_about_relative_paths()
* options that end with "File".
When picking an intro point from the service descriptor, the client failed to
lookup the failure cache.
It made an HS v2 client re-pick bad intro points for which we already know it
won't work in the first place.
Based on Neel Chauhan original patch.
Fixes#25568
Signed-off-by: David Goulet <dgoulet@torproject.org>
Fake circuits are created everywhere in the unit tests. This is an attempt at
centralizing a "fake circuit creation" API like fakechans.c does for channel.
This commit introduces fakecircs.c and changes test_relay.c and
test_circpadding.c which were using roughly the same code.
This will allow easier OR circuit creation for the future tests in
test_circuitmux.c
Signed-off-by: David Goulet <dgoulet@torproject.org>
Also remove a scheduler_init() from a test and MOCK the appropriate function
so the test can pass.
This is done in order to minimize initialization functions in the unit test
and try to only go through the testcase setup object.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Before, when parsing memunits, if overflow occured it failed silently.
Use nowrap u64 math to detect overflow, compare to INT64_MAX and if
greater tell user and fail accordingly.
15000000.5 TB fails double check as it a greater floating number than
(double)INT64_MAX
8388608.1 TB passes double check because it falls in the same value as
(double)INT64_MAX (which is 2^63), but will fail the int check because
(uint64_t)d, which is 2^63, is strictly greater than 2^63-1 (INT64_MAX).
Fixes#30920
Signed-off-by: José M. Guisado <guigom@riseup.net>
If a file doesn't use the file command (either \file or @file),
Doxygen won't try to process it.
These declarations also turned up a doxygen warning for
proto_socks.c; I fixed that too.
If a file doesn't use the file command (either \file or @file),
Doxygen won't try to process it.
These declarations also turned up a doxygen warning for
crypto_ope.c; I fixed that too.
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
confparse.h confmgt.h \
confparse.c confmgt.c \
CONFPARSE_PRIVATE CONFMGT_PRIVATE \
TOR_CONFPARSE_H TOR_CONFMGT_H
options_validate_cb() derives DataDirectory (which we use) from
DataDirectory_option (which the user sets). I want to add a test
that will call options_validate_cb(), but it will fail unless it
derives the same value.
Unlike legacy_validate_fn_t, these callbacks have separation of
duties, into:
* early normalization and computation.
* validation
* transition checking
* late normalization and computation
Only the first and last steps get mutable objects. Only the
transition-checking step gets to see the previous values of this
object.
The former foo_validate() functions are now toplevel
legacy_validate_fn callbacks. The new foo_validate() functions now
call them.
This change lets us remove the old shared_random disk state
validation callback entirely.
As we turn our monolithic configuration objects into suites of
smaller module-specific configuration objects, we will want each one
to be able to provide its own verification callbacks. That means
that instead of invoking these verification callbacks directly, we will
want to call them via the configuration manager object.
The current API of this callback mixes responsibilities, including:
* validation
* transition checking
* processing (modifying) the configuration object.
These will have to be disentangled piece by piece, so for now, we'll
have "legacy" validate functions as well.
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
validate_fn_t legacy_validate_fn_t \
validate_fn legacy_validate_fn
This input was inessential, and none of the tests actually depended
on it or tested anything about it (as can be seen from the fact that
tests all still pass when it's removed).
I tried to generate this commit with a coccinelle script, but it had
trouble parsing a lot of options_validate as it stands. Instead, I
did a search-and-replace to replace "tdata->old_opt," with "NULL,".
Single hop rejection (POST and GET) for HS v3 descriptor now return a 503 code
which is more accurate code from dir-spec.txt and from other rejection case in
the code.
For instance if you are not a relay and you get a POST request, a 503 code is
sent back with a rejection message.
Part of #31958
Signed-off-by: David Goulet <dgoulet@torproject.org>
First, remove the HSDir mention which should not be in that generic function.
Second, move them to debug() level since they are possible error case.
Part of #31958
Signed-off-by: David Goulet <dgoulet@torproject.org>
Before inspecting the p_chan, we must check if the circuit is marked for close
because if it is the case, the channels are nullified from the circuit.
Several valid cases can mark the circuit for close of the directory
connection.
Fixes#31958
Signed-off-by: David Goulet <dgoulet@torproject.org>
hs_client_purge_state() and hs_cache_clean_as_client() can remove a descriptor
from the client cache with a NEWNYM or simply when the descriptor expires.
Which means that for an INTRO circuit being established during that time, once
it opens, we lookup the descriptor to get the IP object but hey surprised, no
more descriptor.
The approach here is minimalist that is accept the race and close the circuit
since we can not continue. Before that, the circuit would stay opened and the
client wait the SockTimeout.
Fixers #28970.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Only use the HS circuit map to know if an introduction circuit is established
or not. No need for a flag to keep state of something we already have in the
circuit map. Furthermore, the circuit map gets cleaned up properly so it will
always have the "latest truth".
This commit also removes a unit test that was testing specifically that flag
but now we rely solely on the HS circuit map which is also tested few lines
below the removed test.
Fixes#32094
Signed-off-by: David Goulet <dgoulet@torproject.org>
Our minimum version is now 0.2.9.5-alpha. Series 0.3.0, 0.3.1,
0.3.2, 0.3.3, and 0.3.4 are now rejected.
Also, extract this version-checking code into a new function, so we
can test it.
Closes ticket 31549.
Also reject 0.3.5.0 through 0.3.5.6-rc as unstable.
There was one that it could not find because it was in a macro definition.
I used the following semantic patch:
@@
expression e1, e2, e3, e4, e5;
@@
options_validate(e1,
e2,
- e3,
- e4,
e5)
Conflicts:
src/feature/dirparse/authcert_parse.c
src/feature/dirparse/ns_parse.c
src/feature/hs/hs_service.c
src/lib/conf/conftesting.h
src/lib/log/log.h
src/lib/thread/threads.h
src/test/test_options.c
These conflicts were mostly related to autostyle improvements, with
one or two due to doxygen fixes.
Since each of these tests only applies to testing networks, put them
all into a single block that checks for testing networks.
(I recommend reviewing with the "diff -b" option, since the change
is mostly indentation.)
Two things needed to be changed. First, we used to set quiet_level
to the default (QUIET_NONE) when running tests, since we would not
call anything that acted based upon it. But since we sometimes call
options_init_logs(), we need to pre-set quiet_level to QUIET_SILENT
in the logs so that we don't add the default logs. This did not
cause test failure: just unwanted logs.
Second, we had a test that checked whether options_validate was
messing with options->Logs correctly. Since options_validate no
longer messes with the logs, we no longer want a test for this.
Formerly, we would use quiet_level as an excuse to rewrite the log
configuration, adding a default log line if none existed, and if
RunAsDaemon was not set, and if we were not being invoked via
setconf (!).
This is against our best practices for several reasons:
* We should not be changing configured options except when the
user tells us to do so.
* We should especially not be changing options in the options_validate
function.
* Distinguishing whether we are being called from setconf adds a
risky special-case.
Instead, this patch take a simpler approach: it changes the
interpretation of having no logging lines set to mean: If there is a
stdout, add a default log based on quiet_level.
Solves ticket 31999.
Since this code passes the same options to options_validate() more
than once, options_validate() needs to be prepared for that. (This
previously worked by accident, since the smartlist of schedulers
wasn't initialized.)
This finally became the empty string, since we no longer have to do
anything in individual test_options.c tests to make "" be a valid
set of options. Now we can remove it at last.
Now that ConnLimit is set to the default value in the
testing helper functions, the individual tests don't all need to
make sure it is set to something valid.
Several of our tests assumed that ConnLimit would be set to 0 by
default, causing the default options not to be parseable. These
tests had nothing to do with ConnLimit.
Now that MaxClientCircuitsPending is set to the default value in the
testing helper functions, the individual tests don't all need to
make sure it is set to something valid.
Several of our tests assumed that MaxClientCircuitsPending would be
set to 0 by default, causing the default options not to be
parseable. These tests had nothing to do with
MaxClientCircuitsPending.
Now that KeepalivePeriod is set to the default value in the testing
helper functions, the individual tests don't all need to make sure
it is set to something valid.
Several of our tests assumed that KeepalivePeriod would be set to 0
by default, causing the default options not to be parseable. These
tests had nothing to do with KeepalivePeriod.
This macro used to have a big list of "default" values that we
needed to set in the test_options tests in order to have reasonable
behavior. But now that we initialize options objects to the default
settings in these tests, we no longer need such a long list of
things to replace.
Previously, we just used options set to all 0s, but this causes some
pretty severe workarounds throughout the code, as our options fail
to validate, or count as "default" for the wrong reasons.
Note that in some places, we stop getting spurious warnings or
failures which the tests previously demanded. In these cases, I've
changed the test behavior.
Fixes 32175.
Relays now respect their AccountingMax bandwidth again. When relays
entered "soft" hibernation (which typically starts when we've hit
90% of our AccountingMax), we had stopped checking whether we should
enter hard hibernation. Soft hibernation refuses new connections and
new circuits, but the existing circuits can continue, meaning that
relays could have exceeded their configured AccountingMax.
This commit rolls back some of the cpu-saving fixes, where we tried
to avoid calling so many of our events while we're off the network.
That's because PERIODIC_EVENT_FLAG_NEED_NET checks net_is_disabled(),
which returns true even if we're only in soft hibernation.
Fixes bug 32108; bugfix on 0.4.0.1-alpha.
* actually sleep when tor has not logged anything
* log at debug level when waiting for tor to log something
* backslash-replace bad UTF-8 characters in logs
* format control messages as ASCII: tor does not accept UTF-8 control commands
Fixes bug 31837; bugfix on 0.3.5.1-alpha.
This patch removes an overly strict tor_assert() and an ignorable BUG()
expression. Both of these would trigger if a PT was unable to configure
itself during startup. The easy way to trigger this is to configure an
obfs4 bridge where you make the obfs4 process try to bind on a port
number under 1024.
See: https://bugs.torproject.org/31091
This patch adds a test to check for whether the exit callback is always
called when process_exec() fails, both on Windows and Unix.
See: https://bugs.torproject.org/31810
This patch fixes an issue where the exit handler is not called for the
given process_t in case CreateProcessA() fails. This could, for example,
happen if the user tries to execute a binary that does not exist.
See: https://bugs.torproject.org/31810
This patch removes a call to tor_assert_unreached() after execve()
failed. This assertion leads to the child process emitting a stack trace
on its standard output, which makes the error harder for the user to
demystify, since they think it is an internal error in Tor instead of
"just" being a "no such file or directory" error.
The process will now instead output "Error from child process: X" where
X is the stringified version of the errno value.
See: https://bugs.torproject.org/31810
We used to have this function so that we could mark our initial
log-to-stdout as specifically temporary so that we would delete it
once regular logs were configured. But it's no longer necessary to
mark these logs as temporary, since we now use a mark-and-sweep
process to ensure that _all_ not-configured logs are closed when we
change our configuration.
Instead, this function will be the basis of a refactoring in how we
handle default logs.
Previously this was done with a big list of options in main.c which
implied "hush" or "quiet". One of these options ("--digests") no
longer existed, but we still checked for it.
Now we use the table of command-line-only arguments to set this
value.
Previously these were implemented with a search in
options_init_from_torrc(), but that led to each option being
declared more than needed: once to say that it was a valid option,
and once to say what it meant.
This commit introduces the hs_desc_decode_status_t enum which aims at having
more fine grained error code when decoding a descriptor.
This will be useful in later commits when we support keeping a descriptor that
can't be decrypted due to missing or bad client authorization creds.
No behavior change.
Part of #30382.
Signed-off-by: David Goulet <dgoulet@torproject.org>
No code behavior change. This removes duplicate code that was finding all
entry connections for a specific onion service identity key.
The find_entry_conns() helper function is introduced for that.
Part of #30382
Signed-off-by: David Goulet <dgoulet@torproject.org>
When tearing down all periodic events during shutdown, disable them first so
their enable flag is updated.
This allows the tor_api.h to relaunch tor properly after a clean shutdown.
Fixes#32058
Signed-off-by: David Goulet <dgoulet@torproject.org>
This commit defines the new extended error codes. It also flags the socks
request object that it can use them.
Part of #30382
Signed-off-by: David Goulet <dgoulet@torproject.org>
This new flag tells tor that it can send back the SOCKS5 extended error code
detailed in prop304.
Part of #30382
Signed-off-by: David Goulet <dgoulet@torproject.org>
In case of error, a negative value will be returned or NULL written into
first supplied argument.
This patch uses both cases to comply with style in the specific files.
A tor_vasprintf error in process_vprintf would lead to a NULL dereference
later on in buf_add, because the return value -1 casted to size_t would
pass an assertion check inside of buf_add.
On the other hand, common systems will fail on such an operation, so it
is not a huge difference to a simple assertion. Yet it is better to
properly fail instead of relying on such behaviour on all systems.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Found by coverity CID 1454769.
There were a second possible leak that is also fixed in this commit.
Fixes#32063
Signed-off-by: David Goulet <dgoulet@torproject.org>
