Nick Mathewson [Thu, 13 Mar 2025 15:37:15 +0000 (11:37 -0400)]
Remove support for "tlssecrets" exporting
Before we could rely on RFC5705 key material exporters,
we did a fairly hinky thing involving the client random,
the server random, and the master secret. These fields
are all opaque in sensible TLS libraries,
and the master secret is quite sensitive.
Therefore, we're removing them.
Some code still refers to them, but it does so behind
a `define(HAVE_WORKING_TOR_TLS_GET_TLSSECRETS)` check,
which macro is now never defined.
Nick Mathewson [Thu, 6 Mar 2025 13:47:55 +0000 (08:47 -0500)]
Stop using time(NULL) for certificate tests.
The canned testing certificates added in order to fix #41041
will start to expire in a couple of months;
to avoid a test failure then, we should only validate
them against a time when they are valid.
Previously, we got away with using time(NULL) because the old
canned certificate (taken from testing.torproject.org)
was not only signed using SHA-1: it was valid until 2043!
Nick Mathewson [Thu, 6 Mar 2025 13:36:00 +0000 (08:36 -0500)]
Fix test failures with openssl security level >= 1
When OpenSSL compiled to run at security level >= 1,
certificates signed using SHA-1 aren't allowed.
We don't generate or use any such certificates in our regular protocol,
but we had a few in our tests.
This commit replaces those certs with the current certs
from www.torproject.org.
Closes #41021. Bugfix on 0.2.8.1 when the tests were introduced.
David Goulet [Tue, 28 Jan 2025 18:27:14 +0000 (13:27 -0500)]
hashx: Move Windows function within another ifdef
Function only used within the hugepage ifdef for Windows so move it there so we
avoid a unused function warning on our Windows CI:
src/ext/equix/hashx/src/virtual_memory.c:30:13: error: 'set_privilege' defined but not used [-Werror=unused-function]
30 | static bool set_privilege(const char* pszPrivilege, BOOL bEnable) {
| ^~~~~~~~~~~~~
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Wed, 18 Dec 2024 16:04:00 +0000 (11:04 -0500)]
hs: Use downloaded counter for HSDir OOM cache cleanup
The OOM cache cleanup is now done by looking at the downloaded counter. The
cleanup process start at 0 and increment it to the next lowest value until
enough bytes have been removed.
This process could be expensive for large amount of descriptors in the cache
but since it is very expensive to increment counters, most cleanup should
happen within a tight range of downloaded counter target.
Fixes #40996
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Wed, 18 Dec 2024 15:24:28 +0000 (10:24 -0500)]
hs: Add downloaded counter to an HSDir cache entry
This adds a counter for the number of times a descriptor is downloaded from an
HSDir. Future commit will change the OOM subsystem to clean that cache based on
the lowest downloaded counts instead of time in cache.
In order to raise the bar even more for an attacker, the downloaded counter is
only marked when the directory request stream is closed. To pull this off, the
HS identifier on the directory connection is populated with the blinded key
requested (only on success). Finally, when the connection closes, we can then
lookup the cache entry with it and increment the counter.
Part of #40996
Signed-off-by: David Goulet <dgoulet@torproject.org>
Warning: Failed to confirm worker threads' start up after timeout.
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(_start+0x2a) [0x56404d21ddaa] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(cpuworker_init+0x53) [0x56404d373d53] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(log_backtrace_impl+0x57) [0x56404d29e1f7] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(main+0x19) [0x56404d21dd59] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(run_tor_main_loop+0xce) [0x56404d22188e] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(threadpool_new+0x295) [0x56404d3e28f5] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(tor_assertion_failed_+0x148) [0x56404d2a9248] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(tor_main+0x49) [0x56404d21e179] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(tor_run_main+0x1e5) [0x56404d221db5] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7f6aa3b1cd7a] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: Tor 0.4.9.0-alpha-dev (git-4f3aafa1e422e9aa): Assertion 0 failed in threadpool_new at /builds/tpo/core/tor/src/lib/evloop/workqueue.c:641: . Stack trace: (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
We are figuring it out but revert this so we can release an alpha.
Jim Newsome [Fri, 15 Nov 2024 00:38:22 +0000 (18:38 -0600)]
test-network: include IPv6 tests unconditionally
Previously we would incorrectly detect that ipv6 isn't supported if the
ping binary isn't present (as it may not be in a relatively stripped
down container image), or if ICMP packets aren't permitted (as they
often aren't in containers).
We don't really have a need to run these network tests on non-IPv6
systems, so it makes more sense to just run them unconditionally.
Jim Newsome [Wed, 30 Oct 2024 15:34:58 +0000 (10:34 -0500)]
CI: use a fixed version of chutney
While chutney currently runs tor's chutney test in its own CI,
it's difficult to guarantee the two won't accidentally diverge.
Probably best to use a fixed version here so that we can control
chutney version bumps and avoid surprise breakage in tor's CI.
This will also free us to intentionally make breaking changes in
chutney (though I don't have any immediate plans for any).
Roger Dingledine [Tue, 15 Oct 2024 06:54:27 +0000 (02:54 -0400)]
don't build preemptive conflux circuits if no predicted ports
Conflux circuit building was ignoring the "predicted ports" feature,
which aims to make Tor stop building circuits if there have been
no user requests lately. This bug led to every idle Tor on the
network building and discarding circuits every 30 seconds, which
added overall load to the network, used bandwidth and battery from
clients that weren't actively using their Tor, and kept sockets open
on guards which added connection padding essentially forever.
Bug went in on commit 39c2927d when we added preemptive conflux circuit
pools.
Resources allocated by cpuworker weren't being freed on clean shutdown.
This applies for worker threads, worker thread pool, reply queue, reply
event, ...
projects / thirdparty / tor.git / log
