The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-01-19T21:23:07Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30187100% cpu usage in winthreads tor_cond_wait2021-01-19T21:23:07ZTrac100% cpu usage in winthreads tor_cond_waitFor years I run relay using self-compiled win64 version of tor.
Compiler mingw64.
Relay runs well for some time but suddenly starts using 100% cpu all cores.
I traced where it happens. The following loop never ends :
```
do {
DWO...For years I run relay using self-compiled win64 version of tor.
Compiler mingw64.
Relay runs well for some time but suddenly starts using 100% cpu all cores.
I traced where it happens. The following loop never ends :
```
do {
DWORD res;
res = WaitForSingleObject(cond->event, ms);
EnterCriticalSection(&cond->lock);
if (cond->n_to_wake &&
cond->generation != generation_at_start) {
--cond->n_to_wake;
--cond->n_waiting;
result = 0;
waiting = 0;
goto out;
} else if (res != WAIT_OBJECT_0) {
result = (res==WAIT_TIMEOUT) ? 1 : -1;
--cond->n_waiting;
waiting = 0;
goto out;
} else if (ms != INFINITE) {
endTime = GetTickCount();
if (startTime + ms_orig <= endTime) {
result = 1; /* Timeout */
--cond->n_waiting;
waiting = 0;
goto out;
} else {
ms = startTime + ms_orig - endTime;
}
}
/* If we make it here, we are still waiting. */
if (cond->n_to_wake == 0) {
/* There is nobody else who should wake up; reset
* the event. */
ResetEvent(cond->event);
}
out:
LeaveCriticalSection(&cond->lock);
} while (waiting);
```
res = WAIT_OBJECT_0;
ms = INFINITE;
cond->n_to_wake=0x11
cond->generation=0x28
generation_at_start=0x28
it means no path with "goto out" ever execute
more than one thread run this loop and each one eat separate core
Some people I shared binaries with report same problem.
Pls check
**Trac**:
**Username**: bolvanTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/33832For relays that change ip, only the measurements with the last ip are kept2020-12-18T09:41:15ZjugaFor relays that change ip, only the measurements with the last ip are keptwhich makes those relays more likely to don't be "eligible" cause don't have enough results and therefore, sbws voting in less relays.which makes those relays more likely to don't be "eligible" cause don't have enough results and therefore, sbws voting in less relays.sbws: 1.1.x-finaljugajugahttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/33831Relays without descriptors are not scaled, but still added to the bwlines wit...2020-11-30T11:49:39ZjugaRelays without descriptors are not scaled, but still added to the bwlines without vote=0As can be seen in: https://gitweb.torproject.org/sbws.git/tree/sbws/lib/v3bwfile.py?h=maint-1.1#n1317
As a result, some relays (in sample data counted ~800) are included in the bandwidth file without its bandwidth scaled, which could b...As can be seen in: https://gitweb.torproject.org/sbws.git/tree/sbws/lib/v3bwfile.py?h=maint-1.1#n1317
As a result, some relays (in sample data counted ~800) are included in the bandwidth file without its bandwidth scaled, which could be quite different (higher or lower) than the scaled bandwidth.
This is one of the several reasons of legacy/trac#33775.sbws: 1.1.x-finaljugajugahttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/33472Document that bwauths should checkout stable versions when installing sbws fr...2020-07-14T16:44:07ZjugaDocument that bwauths should checkout stable versions when installing sbws from giti think that if some bwauths are installing sbws from git, they should checkout a tag or a bugfix branch. We might want to have a bwauth to run a development branch, but it should be only one.i think that if some bwauths are installing sbws from git, they should checkout a tag or a bugfix branch. We might want to have a bwauth to run a development branch, but it should be only one.sbws: 1.1.x-finaljugajugahttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/33009sbws bandwidth scans should require a minimum exit bandwidth2022-02-11T09:53:47Zteorsbws bandwidth scans should require a minimum exit bandwidthWhen sbws is constructing a two-hop measurement circuit to run a test, it tries to pick an exit that has at least twice the consensus weight of the current relay-under-test:
https://github.com/torproject/sbws/blob/master/sbws/core/scanne...When sbws is constructing a two-hop measurement circuit to run a test, it tries to pick an exit that has at least twice the consensus weight of the current relay-under-test:
https://github.com/torproject/sbws/blob/master/sbws/core/scanner.py#L216
So this means that in this case, sbws would have picked any exit that was not a BadExit, has an acceptable ExitPolicy, and has a consensus weight of at least, well, 2. That's not a lot.
As it turns out, something like 10% of exits have under a 600Kbyte/sec advertised bandwidth. So it seems pretty easy from this weight=1 bootstrap scenario to get paired with an exit that will give poor test results.
Perhaps bwauth path selection should also choose a testing pair from exits/relays with a certain absolute minimum of weight or advertised bandwidth?
Reported by Jimmy on tor-relays:
https://lists.torproject.org/pipermail/tor-relays/2020-January/018027.htmlsbws: 1.1.x-finalGeorg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/29722Document that authorities are not measured2020-06-27T13:41:18ZjugaDocument that authorities are not measuredsbws: 1.1.x-finaljugajugahttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40112libstdc++.so.6 not stripped2021-01-20T18:56:24Zyanmaanilibstdc++.so.6 not strippedIn `tor-browser-build/projects/tor/build`, `libstdc++.so.6` is copied from GCC to the output:
```
# We need to copy the libstdc++.so.6 for Tor Browser on older Linux distros.
# Copying it into /Browser, which feels more natural, and ...In `tor-browser-build/projects/tor/build`, `libstdc++.so.6` is copied from GCC to the output:
```
# We need to copy the libstdc++.so.6 for Tor Browser on older Linux distros.
# Copying it into /Browser, which feels more natural, and amending
# LD_LIBRARY_PATH breaks updates from a Tor Browser with the old
# LD_LIBRARY_PATH value to the Tor Browser with the newer one. Thus, we copy
# the libstdc++ into the directory with the libs tor depends on, too. See bug
# 13359 for further details.
mkdir -p "$distdir/Tor/libstdc++"
cp /var/tmp/dist/gcc/[% c("var/libdir") %]/libstdc++.so.6 "$distdir/Tor/libstdc++/"
[% IF c("var/asan") -%]
cp /var/tmp/dist/gcc/[% c("var/libdir") %]/libasan.so.5 "$distdir/Tor/"
cp /var/tmp/dist/gcc/[% c("var/libdir") %]/libubsan.so.1 "$distdir/Tor/"
[% END -%]
chmod 700 "$distdir"/Tor/*.so*
chmod 700 "$distdir"/Tor/libstdc++/*.so*
```
This file is unstripped and contains debug info. Stripping it takes it from 17 MB to 2 MB, without any impact on functionality as far as I can tell. After compression, the entire tarball is 3MB smaller.
This should be a one-line change, provided `strip` is deterministic. I haven't looked into it.Tor Browser: 10.5https://gitlab.torproject.org/tpo/core/arti/-/issues/164Brainstorm some example programs to ship with arti 0.0.12021-10-29T16:25:01ZNick MathewsonBrainstorm some example programs to ship with arti 0.0.1We've found that example code is a good way to teach the APIs, and also to make sure that the APIs are nice and simple.
This is not the ticket for writing that example code; this is the ticket for deciding what we want to write in order...We've found that example code is a good way to teach the APIs, and also to make sure that the APIs are nice and simple.
This is not the ticket for writing that example code; this is the ticket for deciding what we want to write in order to document and refine our APIs a little in our 0.0.1 milestone phase.
cc @dgoulet @ahfArti 0.0.1 release: basic anonymityhttps://gitlab.torproject.org/tpo/core/arti/-/issues/149MockSleepRuntime::wait_for doesn't work very well.2021-10-26T17:14:56ZNick MathewsonMockSleepRuntime::wait_for doesn't work very well.For testing, we have the capacity to replace the regular timer implementation from our asynchronous runtime with a fake one that doesn't ever have to actually wait. That's `MockSleepProvider` and `MockSleepRuntime` in the `tor-rtmock` cr...For testing, we have the capacity to replace the regular timer implementation from our asynchronous runtime with a fake one that doesn't ever have to actually wait. That's `MockSleepProvider` and `MockSleepRuntime` in the `tor-rtmock` crate.
We also provide another function that tries to run a future to completion, while advancing "mock time" step by step until it is ready. That's `MockSleepRuntime::wait_for` in `tor-rtmock/src/sleep_runtime.rs`. But unfortunately, it doesn't work too well, and I'm not sure why. I had it advancing one millisecond at a time, but the tests would fail under some circumstances when I did that (specifically, the circmgr tests under test coverage). I had to decrease the increment to 10 microseconds to make it work, which suggests to me that there is some fundamental problem in this code with making sure that all our futures get polled when they ought to get polled.
I'm marking this as ~"First Contribution" , but it is probably not a good fit for anybody without a deep understanding of Rust async implementations and their internals. On the other hand, if you know that stuff very well, you probably don't need to know Arti at all to solve this ticket.Arti 0.0.1 release: basic anonymityetaetahttps://gitlab.torproject.org/tpo/core/arti/-/issues/52Add a test framework for the path selection algorithm2021-09-08T15:15:27ZLunarAdd a test framework for the path selection algorithm`DirPathBuilder.pick_path` and `ExitPathBuilder.pick_path` currently lack tests. Ideally, we would want to add some way to test these methods against various network topology and check the selected paths.
What I thought of, so far:
- mo...`DirPathBuilder.pick_path` and `ExitPathBuilder.pick_path` currently lack tests. Ideally, we would want to add some way to test these methods against various network topology and check the selected paths.
What I thought of, so far:
- mock DirInfo and most of the objects it references,
- create a consensus document from a human readable description of the network and then parse it into a DirInfo,
- instantiate a full DirInfo using code to help us do that.
The [testing category on crates.io](https://crates.io/categories/development-tools::testing) is worth investigating.
Anyway, this issue is mostly for collecting ideas for now, so if you have any, or even a suggestion of what should be done exactly, let's hear it. :)Arti 0.0.1 release: basic anonymityhttps://gitlab.torproject.org/tpo/core/arti/-/issues/43Make sure that a circuit doesn't use relays in the same family2021-08-05T19:18:35ZNick MathewsonMake sure that a circuit doesn't use relays in the same familyMoved from #28.
To do this:
- [x] Start by implementing a "same-family?" predicate in tor-netdir, probably as a method for the Relay type.
- [x] Then use this predicate in tor-circmgr/path/exitpath.rs.
- [x] Implement something...Moved from #28.
To do this:
- [x] Start by implementing a "same-family?" predicate in tor-netdir, probably as a method for the Relay type.
- [x] Then use this predicate in tor-circmgr/path/exitpath.rs.
- [x] Implement something like the `EnforceDistinctSubnets` feature from C tor.Arti 0.0.1 release: basic anonymityhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40316Patch GeckoView's ConnectivityManager usage2022-11-30T15:19:48ZMatthew FinkelPatch GeckoView's ConnectivityManager usageGeckoView uses the connectivity manager for detecting the currently used [type of network connection](https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/tor-browser-86.0b1-10.5-1/mobile/android/geckoview/src/main/java/org/...GeckoView uses the connectivity manager for detecting the currently used [type of network connection](https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/tor-browser-86.0b1-10.5-1/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoAppShell.java#L1170) (WIFI, 2G, 3G, 4G, etc). I didn't dig into the code, but it looks like some gecko behavior changes depending on the link type. Along with removing the `WIFI_STATE` Android permission, we should make sure this isn't [leaking any info into content](https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/tor-browser-86.0b1-10.5-1/dom/html/HTMLMediaElement.cpp#L2914), and we should probably just always return `LINK_TYPE_UNKNOWN`.Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40145Investigate alt-svc validation and cache eviction2023-11-27T08:30:55ZMatthew FinkelInvestigate alt-svc validation and cache evictionAfter connecting to a site that sends an alt-svc onion header (such as a site fronted by Cloudflare), Tor Browser receives an alt-svc. When Firefox receives an alt-svc, it establishes a connection with it as verification that it is usefu...After connecting to a site that sends an alt-svc onion header (such as a site fronted by Cloudflare), Tor Browser receives an alt-svc. When Firefox receives an alt-svc, it establishes a connection with it as verification that it is useful and usable. There seems to be a bug in Firefox (or Tor Browser) where this verification continues indefinitely, regardless of whether the original site is still open.
I'm not sure if this is because every response from Cloudflare's IP address site may return a different alt-srv, and Tor Browser connects with the IP address when the alt-srv connection fails or the connection cache is bypassed, therefore Tor Browser creates a very long lists of sites it should contact and verify. Or, maybe Tor Browser enters an infinite loop (or finite but sufficiently large in size) of testing the alt-srv's in its list, and never marks them as valid. I'm not sure why this is happening.
However, the most problematic and concerning result is that Tor Browser continually tries connecting with these sites long after any tabs for that site are closed.Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/web/community/-/issues/213Come up with a better terminology for bridges2021-10-27T13:31:53ZPhilipp Winterphw@torproject.orgCome up with a better terminology for bridgesOur terminology for bridges is confusing:
* *Private* bridges are bridges that BridgeDB doesn't know about. Users may mistakenly conclude that if a bridge isn't private, it must be public, which is incorrect. Suggestions for other terms:...Our terminology for bridges is confusing:
* *Private* bridges are bridges that BridgeDB doesn't know about. Users may mistakenly conclude that if a bridge isn't private, it must be public, which is incorrect. Suggestions for other terms: unshared, exclusive, unlisted, unknown.
* *Default* bridges are part of Tor Browser. Conceptually, default bridges are more like obfs4-enabled guard relays. Suggestions for other terms: built-in (we may have been using that term occasionally), standard, public.
* We don't have a consistent term for bridges that are distributed by BridgeDB/rdsys. Perhaps we don't need a term because that's the default?
How can we improve the situation?
Copying @cohosh, @antonela, @arma, and @gus.
# Update
proposal is to change this terminology **everywhere**
- default bridges -> built-in bridges
- will not do private/public bridges anymore
- private bridges -> secret bridges
- public bridges -> distributed bridges
Everywhere means:
- [ ] documentation - needs tickets in each portal
- [ ] [Browser's UI](tpo/applications/tor-browser#40623)
- [ ] Code - needs ticketSponsor 30 - Objective 2.2GusGushttps://gitlab.torproject.org/tpo/anti-censorship/bridge-port-scan/-/issues/2Make HTML use our torproject.org CSS style2022-01-20T21:31:11ZPhilipp Winterphw@torproject.orgMake HTML use our torproject.org CSS styleOur static CSS files are available here: https://gitlab.torproject.org/tpo/web/lego/-/tree/master/assets
The site is in https://bridges.torproject.org/scanOur static CSS files are available here: https://gitlab.torproject.org/tpo/web/lego/-/tree/master/assets
The site is in https://bridges.torproject.org/scanSponsor 30 - Objective 2.2https://gitlab.torproject.org/tpo/core/tor/-/issues/29617OOM manger wipes entire DNS cache2020-06-27T13:50:46ZpullsOOM manger wipes entire DNS cacheIn relay.c, function cell_queues_check_size, the OOM manager attempts to clear one tenth of MaxMemInQueues bytes from the DNS cache by calling dns_cache_handle_oom. The function dns_cache_handle_oom, in dns.c, runs in a loop removing cac...In relay.c, function cell_queues_check_size, the OOM manager attempts to clear one tenth of MaxMemInQueues bytes from the DNS cache by calling dns_cache_handle_oom. The function dns_cache_handle_oom, in dns.c, runs in a loop removing cached entries that are now+n*time_inc old, until at least the requested number of bytes have been freed. The first iteration of the loop has n=0, and likely will not remove enough bytes. The second iteration is way too aggressive, because:
```
time_inc += 3600; /* Increase time_inc by 1 hour. */
```
This is guaranteed to wipe the entire DNS cache, because in dns_clip_ttl the maximum time to cache is MAX_DNS_TTL_AT_EXIT, which is set in dns.h to:
```
/** Lowest value for DNS ttl that a server will give. */
#define MIN_DNS_TTL_AT_EXIT (5*60)
/** Highest value for DNS ttl that a server will give. */
#define MAX_DNS_TTL_AT_EXIT (60*60)
```
One possible and reasonable fix would be to instead increment time_inc by MIN_DNS_TTL_AT_EXIT.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28895"Your guard" log messages are causing confusion2020-06-27T13:51:21ZGeorge Kadianakis"Your guard" log messages are causing confusionSee this thread https://lists.torproject.org/pipermail/tor-talk/2018-December/044756.html for some confusion that is called by the pathbias log messages refering to guards.
We should improve them since they tend to confuse and agitate u...See this thread https://lists.torproject.org/pipermail/tor-talk/2018-December/044756.html for some confusion that is called by the pathbias log messages refering to guards.
We should improve them since they tend to confuse and agitate users.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28698When circuit times are fixed, they can't be "relaxed"2020-06-27T13:51:29ZteorWhen circuit times are fixed, they can't be "relaxed"In legacy/trac#28639, we had trouble diagnosing a sbws bug. tor said that circuit times were "relaxed", even when LearnCircuitBuildTimeout was 0.
When circuit_build_times_disabled() is true, we should change these log messages so that t...In legacy/trac#28639, we had trouble diagnosing a sbws bug. tor said that circuit times were "relaxed", even when LearnCircuitBuildTimeout was 0.
When circuit_build_times_disabled() is true, we should change these log messages so that they make sense:
https://github.com/torproject/tor/blob/b058f64cc002b44e6dd48616ca3163a01c3f3e14/src/core/or/circuituse.c#L591
I think relaxed_timeout is meaningless when circuit_build_times_disabled() is true, but that's another issue.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27204add info for IPv6-only hosts to torrc man page2021-07-22T16:20:36Ztraumschuleadd info for IPv6-only hosts to torrc man pageAdd a sentence to the ClientUseIPv6 section of the tor man page:
> For IPv6 only hosts, you need to also set **ClientUseIPv4** to 0 to disable IPv4.Add a sentence to the ClientUseIPv6 section of the tor man page:
> For IPv6 only hosts, you need to also set **ClientUseIPv4** to 0 to disable IPv4.Tor: 0.3.5.x-finaltraumschuletraumschulehttps://gitlab.torproject.org/tpo/core/tor/-/issues/27040[warn] We don't have a consensus, so we can't perform v2 rendezvous operations.2020-06-27T13:52:40ZRoger Dingledine[warn] We don't have a consensus, so we can't perform v2 rendezvous operations.Start your Tor, and while it's bootstrapping, make an onion service request. (In my case I started 'apt-get update' which uses the apt-transport trick to make it use my Tor.)
Now I have in my logs:
```
Jul 30 20:27:11.890 [notice] Boot...Start your Tor, and while it's bootstrapping, make an onion service request. (In my case I started 'apt-get update' which uses the apt-transport trick to make it use my Tor.)
Now I have in my logs:
```
Jul 30 20:27:11.890 [notice] Bootstrapped 25%: Loading networkstatus consensus
Jul 30 20:27:21.285 [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.
Jul 30 20:27:21.285 [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.
Jul 30 20:27:21.285 [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.
Jul 30 20:27:21.285 [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.
Jul 30 20:27:21.286 [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.
Jul 30 20:27:21.286 [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.
Jul 30 20:29:21.379 [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.
Jul 30 20:29:21.379 [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.
Jul 30 20:29:21.384 [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.
Jul 30 20:29:21.384 [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.
Jul 30 20:29:21.385 [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.
Jul 30 20:29:21.385 [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.
Jul 30 20:29:58.498 [notice] Bootstrapped 45%: Asking for relay descriptors
```
I think maybe it shouldn't warn like that if it hasn't bootstrapped yet? Or, is there some specific value to warning there?Tor: 0.3.5.x-final