This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
directory_must_use_begindir dirclient_must_use_begindir \
directory_fetches_from_authorities dirclient_fetches_from_authorities \
directory_fetches_dir_info_early dirclient_fetches_dir_info_early \
directory_fetches_dir_info_later dirclient_fetches_dir_info_later \
directory_too_idle_to_fetch_descriptors dirclient_too_idle_to_fetch_descriptors
To make Tor still work, we define a minimal dircache_stub.c file
that defines the entry points to the module that can actually be
seen by the compiler when we're building with dircache and relay
disabled.
This function had some XXX comments indicating (correctly) that it
was not actually used by the dirserver code, and that only the
controller still used it.
For now, this module is enabled whenever the relay module is
enabled, and disabled whenever the relay module is disabled. Though
they are logically separate, the use cases for running one without
the other are rare enough that we don't really want to support
compiling them independently.
We already check if there are invalid values in
check_bridge_distribution_setting() and reject the value if that is the
case. We can therefore only have strings of [A-Z] | [a-z] | [0-9] | '-'
| '_' here which is according to the directory specification.
See: https://bugs.torproject.org/32753
Fix dirauth and relay module include.am add_c_file.py
"control line not preceded by a blank line" errors.
Also remove a duplicate ADD_C_FILE: SOURCES in the relay module.
Obviously correct fixes to already-reviewed code.
* fname for generic file paths
* tor_fname for paths relative to the top-level tor directory
* src_fname for paths relative to tor's src directory
With prefixes as required to disambiguate different paths of the same
type.
Part of 32962.
* distinguish between paths relative to the top-level tor directory,
and paths relative to tor's src directory
* canonicalise paths before using them
* check that the script is run from the top-level tor directory
* check that the file is being created in tor's src directory
Part of 32962.
This patch makes sure we lowercase the value of BridgeDistribution
before we add it to the descriptor as `bridge-distribution-request`.
See: https://bugs.torproject.org/32753
This patch makes sure that we accept values such as "nOne", "None", and
"AnY" as valid values for BridgeDistribution. We later ensure to
lower-case the values before they are forwarded to the BridgeDB.
See: https://bugs.torproject.org/32753
When the BridgeDistribution value was added in commit
ebab521525 the check for whether the value
contains '\n' or '\r' was added as a requirement for whether or not the
value should be escaped.
This patch removes this check and makes sure we call `escaped()` on the
value every time before we add it to a descriptor.
See: https://bugs.torproject.org/32753
When we made these functions exist unconditionally (as macros on
non-windows platforms), we started to get a dead-code warning on
Coverity. We now use a macro to tell coverity not to worry about
this particular dead-code instance.
The POSSIBLE(e) macro evaluates to the value of (e), but does so in
a way that a static analyzer will not conclude that (e) is
impossible. We can use this when we expect our regular compilers to
eliminate deadcode, but we don't want coverity to complain about it.
Part of a fix for 32960.
"Ours" merge, because ticket 32883 replaces this code with calls
to tor_run_main(). (Which then calls the pubsub functions.)
Therefore, this PR is obsolete in master, but it still needs to be
merged, to avoid conflicts during any future backport.
And canonicalise file paths, so that output is consistent, even in
out-of-tree builds.
Capturing stderr output produces better diagnostics.
Diagnostics for 32705.
We need a test branch for the earliest maint branch (maint-0.3.5),
but we can't merge forward into it, because there is no previous
active maint branch.
Also, edit a git-push-all comment that still said "029".
Bugfix on 32772; bug not in any released version of tor.
The variable lenght cells are handled directly by
channel_tls_handle_var_cell() from an OR connection reading its inbuf. The
channel var cell handler (agnostic) was never used.
Closes#32892
Signed-off-by: David Goulet <dgoulet@torproject.org>
We hit this assertion with bug 32868, but I'm stymied figuring out
how we wound up with a routerstatus like this. This patch is a
diagnostic to attempt to figure out what is going on, and to avoid a
crash in the meantime.
