We suspect a shutdown race of some sort for which the full teardown is not
noticed during the close but should be during the free.
For that, we flag the conflux set as in full teardown (if so) in the free path
in case the close path didn't caught it.
Fixes#40870
Signed-off-by: David Goulet <dgoulet@torproject.org>
This has been misspelled when using consensus method 31 or later
since 0.4.6.1-alpha. Fixes bug 40869.
This commit is a backport of b9b0abd6c2 to 0.4.8.
This patch causes `tor_compress_is_compression_bomb()` to emit a
warning-level log message that lets us learn the potential ratio of the
input to output buffer sizes. Hopefully, this will give us a bit of a
better idea whether the compression bomb ratio needs some tuning.
See: tpo/core/tor#40739.
This patch removes a call to `tor_assert_nonfatal_unreached()` in
`relay_key_is_unavailable_()` that is only called when Tor is compiled
without relay support.
Unfortunately, the non-fatal assertion causes a BUG log
message to appear for clients when they start up without relay support
for each CPU worker we spawn. This makes it spotting issues during
bootstrap harder particularly for our iOS developers.
Since the call sites to `get_master_identity_key()` handles `NULL`
values already, we do not think this will be an issue later on.
Reported by Benjamin Erhart (@tla) from Guardian Project.
Fixes tpo/core/tor#40848.
When we implemented prop275 in 0.4.8.1-alpha, we changed the
behavior of networkstatus_getinfo_helper_single to omit meaningful
published_on times, replacing them with "2038-01-01". This is
necessary when we're formatting a routerstatus with no additional
info, since routerstatus objects no longer include a published_on.
But in networkstatus_getinfo_by_purpose, we do have a routerinfo
that does have a published_on. This patch uses that information
to report published_on times in our output when we're making a
"virtual" networkstatus for a big file of routerinfo_t objects.
This is mostly important for bridge authorities, since when
they dump a secret list of the bridges, they want to include
published_on times.
Closes#40855. Bugfix on 0.4.8.1-alpha.
This commit adds a new consensus method which, when present, causes
authorities not to consider package fingerprints when computing a
consensus. It builds on earlier work which dropped support for putting
these lines into the votes.
Considering a compression bomb before looking for errors led to false negative
log warnings. Instead, it is possible the work failed for whatever reasons
which is not indicative of a compression bomb.
Fixes#40739
Signed-off-by: David Goulet <dgoulet@torproject.org>
Rotate to a new L2 vanguard whenever an existing one loses the
Stable or Fast flag. Previously, we would leave these relays in the
L2 vanguard list but never use them, and if all of our vanguards
end up like this we wouldn't have any middle nodes left to choose
from so we would fail to make onion-related circuits.
Fixes bug 40805; bugfix on 0.4.7.1-alpha.
This addresses issue #40800 and a couple other problems I noticed while
trying to reproduce that one.
The original issue is just a missing cast to void* on the args of
__builtin___clear_cache(), and clang is picky about the implicit cast
between what it considers to be char of different signedness. Original
report is from MacOS but it's also reproducible on other clang targets.
The cmake-based original build system for equix and hashx was a handy
way to run tests, but it suffered from some warnings due to incorrect
application of include_directories().
And lastly, there were some return codes from hashx_exec() that get
ignored on equix when asserts are disabled. It bugged me too much to
just silence this with a (void) cast, since even though this is in the
realm of low-likelyhood programming errors and not true runtime errors, I
don't want to make it easy for the hashx_exec() wrappers to return
values that are dangerously wrong if an error is ignored. I made sure
that even if asserts are disabled, we return values that will cause the
solver and verifier to both fail to validate a potential solution.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
This fixes an "initializer is not a constant" compilation error that manifests
itself on gcc versions < 8.1 and MSVC (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960#c18).
Fixes bug #40773
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
