The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-02-11T09:53:47Zhttps://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/core/tor/-/issues/34382Don't require M_SYSCALL in sandbox.c2022-07-07T00:49:01ZNick MathewsonDon't require M_SYSCALL in sandbox.cIn sandbox.c, we have a platform-dependent M_SYSCALL macro that is used to extract the syscall from a ucontext_t pointer.
But we only use this value for debugging. Perhaps instead we should make it optional, so that platforms where we ...In sandbox.c, we have a platform-dependent M_SYSCALL macro that is used to extract the syscall from a ucontext_t pointer.
But we only use this value for debugging. Perhaps instead we should make it optional, so that platforms where we don't have it defined can still build with m_syscall.
See also legacy/trac#32904 and legacy/trac#30987Tor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34311Space out code in relay.c2020-06-27T13:47:38ZNeel Chauhanneel@neelc.orgSpace out code in relay.cYes, I do understand that Tor is working on automatic code checks for things like code spacing and that I should work on that instead of sending spacing patches, but I still noticed a lot of spacing issues in relay.c (more than normal) s...Yes, I do understand that Tor is working on automatic code checks for things like code spacing and that I should work on that instead of sending spacing patches, but I still noticed a lot of spacing issues in relay.c (more than normal) so I just **had** to submit this.
My PR fixes all (or at least most) of relay.c.Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34246Add a link to the formatted architecture docs in src/mainpage.md2021-07-22T16:18:20ZteorAdd a link to the formatted architecture docs in src/mainpage.mdWhen I open up src/mainpage.md. it's obviously meant to be formatted by a markdown parser. (And GitHub's markdown doesn't seem to handle "@" directives.)
Can you add a link to the formatted output at the top of mainpage.md ?When I open up src/mainpage.md. it's obviously meant to be formatted by a markdown parser. (And GitHub's markdown doesn't seem to handle "@" directives.)
Can you add a link to the formatted output at the top of mainpage.md ?Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34245Declare variables in for loops in rend_service_dump_stats()2022-07-07T00:49:01ZNeel Chauhanneel@neelc.orgDeclare variables in for loops in rend_service_dump_stats()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34238Space out some function calls in parse_short_policy()2022-07-07T00:49:01ZNeel Chauhanneel@neelc.orgSpace out some function calls in parse_short_policy()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34237Fix spacing in if statement in tor_version_parse()2022-07-07T00:49:00ZNeel Chauhanneel@neelc.orgFix spacing in if statement in tor_version_parse()This if statement in tor_version_parse():
```
if ( hexlen == 0 || (hexlen % 2) == 1)
```
should be:
```
if (hexlen == 0 || (hexlen % 2) == 1)
```This if statement in tor_version_parse():
```
if ( hexlen == 0 || (hexlen % 2) == 1)
```
should be:
```
if (hexlen == 0 || (hexlen % 2) == 1)
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34236Fix spacing in if statement in port_parse_config()2020-06-27T13:47:46ZNeel Chauhanneel@neelc.orgFix spacing in if statement in port_parse_config()This line in `port_parse_config()`:
```
if ( has_used_unix_socket_only_option && ! unix_socket_path) {
```
should be:
```
if (has_used_unix_socket_only_option && !unix_socket_path) {
```This line in `port_parse_config()`:
```
if ( has_used_unix_socket_only_option && ! unix_socket_path) {
```
should be:
```
if (has_used_unix_socket_only_option && !unix_socket_path) {
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33883Fix typo in router_build_fresh_unsigned_routerinfo() comment2020-06-27T13:47:53ZNeel Chauhanneel@neelc.orgFix typo in router_build_fresh_unsigned_routerinfo() commentThis comment in `router_build_fresh_unsigned_routerinfo()`:
```
/* If there is no valud IPv6 ORPort, the address and port are null. */
```
should be:
```
/* If there is no valid IPv6 ORPort, the address and port are null. */
```This comment in `router_build_fresh_unsigned_routerinfo()`:
```
/* If there is no valud IPv6 ORPort, the address and port are null. */
```
should be:
```
/* If there is no valid IPv6 ORPort, the address and port are null. */
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33779Fix incorrect PublishHidServDescriptors value in logs2021-06-23T17:22:41ZteorFix incorrect PublishHidServDescriptors value in logsThis code should say:
"PublishHidServDescriptors is set to 0."
But it says:
```
/* Let's avoid doing that if tor is configured to not publish. */
if (!get_options()->PublishHidServDescriptors) {
log_info(LD_REND, "Service %s not...This code should say:
"PublishHidServDescriptors is set to 0."
But it says:
```
/* Let's avoid doing that if tor is configured to not publish. */
if (!get_options()->PublishHidServDescriptors) {
log_info(LD_REND, "Service %s not publishing descriptor. "
"PublishHidServDescriptors is set to 1.",
safe_str_client(service->onion_address));
goto end;
}
```
I'll leave it to dgoulet and asn to fix, and decide how far it needs to be backported.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33555Space out the line.key/line.value in test_policy_summary_helper_family_flags()2020-06-27T13:48:05ZNeel Chauhanneel@neelc.orgSpace out the line.key/line.value in test_policy_summary_helper_family_flags()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33463Correct spacing in dns_launch_correctness_checks()2020-06-27T13:48:07ZNeel Chauhanneel@neelc.orgCorrect spacing in dns_launch_correctness_checks()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33275Tor Manual: Alphabetize Remaining Tor Manual2021-07-22T16:18:20ZTracTor Manual: Alphabetize Remaining Tor ManualAlphabetically sort the options in the following sections:
- DENIAL OF SERVICE MITIGATION OPTIONS
- DIRECTORY AUTHORITY SERVER OPTIONS
- HIDDEN SERVICE OPTIONS
- TESTING NETWORK OPTIONS
**Trac**:
**Username**: swatiAlphabetically sort the options in the following sections:
- DENIAL OF SERVICE MITIGATION OPTIONS
- DIRECTORY AUTHORITY SERVER OPTIONS
- HIDDEN SERVICE OPTIONS
- TESTING NETWORK OPTIONS
**Trac**:
**Username**: swatiTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32994Get all flag defaults from port_cfg_new()2021-09-16T14:22:17ZteorGet all flag defaults from port_cfg_new()The Tor port flags code is needlessly complex. To change a default, you need to change:
* port_cfg_new()
* port_parse_config()
* connection_listener_new()
We should call port_cfg_new() for the defaults in all these cases.The Tor port flags code is needlessly complex. To change a default, you need to change:
* port_cfg_new()
* port_parse_config()
* connection_listener_new()
We should call port_cfg_new() for the defaults in all these cases.Tor: 0.4.4.x-finalMrSquancheeMrSquancheehttps://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/core/tor/-/issues/40236configure summary misleadingly indicates library support based on enable, not...2022-07-07T00:48:32ZAlex Xuconfigure summary misleadingly indicates library support based on enable, not havewhen --enable-zstd, --enable-lzma, etc are set to auto, they are listed in the configure summary as "no" regardless of whether they were detected and used.when --enable-zstd, --enable-lzma, etc are set to auto, they are listed in the configure summary as "no" regardless of whether they were detected and used.Tor: 0.4.5.x-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/32178Tor adds trailing space character to log events2020-11-03T14:07:14ZRoger DingledineTor adds trailing space character to log eventsFirst noticed in legacy/trac#32164, where Tor Browser's "view of Tor logs" has a bonus space at the end of every line.
I believe it's Tor adding the space. This super simple hack:
```
diff --git a/src/feature/control/control_events.c b/...First noticed in legacy/trac#32164, where Tor Browser's "view of Tor logs" has a bonus space at the end of every line.
I believe it's Tor adding the space. This super simple hack:
```
diff --git a/src/feature/control/control_events.c b/src/feature/control/control_events.c
index 82ea943999..5ddfffeee8 100644
--- a/src/feature/control/control_events.c
+++ b/src/feature/control/control_events.c
@@ -1328,6 +1328,7 @@ control_event_logmsg(int severity, log_domain_mask_t domain, const char *msg)
default: s = "UnknownLogSeverity"; break;
}
++disable_log_messages;
+ printf("Sending \"650 %s %s\"\n", s, b?b:msg);
send_control_event(event, "650 %s %s\r\n", s, b?b:msg);
if (severity == LOG_ERR) {
/* Force a flush, since we may be about to die horribly */
```
shows it:
```
Sending "650 INFO circuit_free_(): Circuit 0 (id: 4) has been freed. "
```
I believe it comes from this snippet in control_event_logmsg():
```
if (strchr(msg, '\n')) {
char *cp;
b = tor_strdup(msg);
for (cp = b; *cp; ++cp)
if (*cp == '\r' || *cp == '\n')
*cp = ' ';
}
```
That is, we send in log lines that have \n in them, and the function helpfully turns the \n into a ' '.
Bug went into Tor 0.1.1.1-alpha in commit c2f6fe9b (way back in the days of the v0 control protocol).Tor: 0.4.5.x-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32661Document that we avoid changing src/ext2021-07-22T16:19:07ZteorDocument that we avoid changing src/extWe only change src/ext when necessary for integration with tor, or portability across platforms.
There was some confusion about this in legacy/trac#32626, so I'd like to update one or more of the following documents:
* src/mainpage.md
*...We only change src/ext when necessary for integration with tor, or portability across platforms.
There was some confusion about this in legacy/trac#32626, so I'd like to update one or more of the following documents:
* src/mainpage.md
* src/ext/README
* doc/HACKING/CodeStructure.md
We might also want to change our merge policy, but that's a longer process.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18106Rename fascist_firewall_* functions to reachable_address_*2021-09-16T14:34:11ZteorRename fascist_firewall_* functions to reachable_address_*In legacy/trac#17840 and legacy/trac#9067 / legacy/trac#9068, we unified ReachableAddresses and ClientUseIPv4/ClientUseIPv6/UseBridges. We'd previously unified FascistFirewall, FirewallPorts and ReachableAddresses.
This means that the f...In legacy/trac#17840 and legacy/trac#9067 / legacy/trac#9068, we unified ReachableAddresses and ClientUseIPv4/ClientUseIPv6/UseBridges. We'd previously unified FascistFirewall, FirewallPorts and ReachableAddresses.
This means that the functions called fascist_firewall_* should probably be renamed to be more descriptive.
I think reachable_address_* is one option, but let's follow typical naming standards and not repeat words in names:
* fascist_firewall_choose_address_dir_server ->
* reachable_address_choose_address_dir_server ->
* reachable_address_choose_dir_server
Let's also use this as an opportunity to disambiguate fascist_firewall_choose_address_impl & fascist_firewall_choose_address_base.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewson