Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T16:16:20Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33009sbws bandwidth scans should require a minimum exit bandwidth2020-06-13T16:16:20Zteorsbws 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/legacy/trac/-/issues/33006Fix test-stem `test_take_ownership_via_controller` failure2020-06-13T15:50:04ZteorFix test-stem `test_take_ownership_via_controller` failureStem's `test_take_ownership_via_controller` test fails when run in Travis CI. This is a recent failure, some time in the last month or two.
See, for example:
https://travis-ci.org/torproject/tor/jobs/639546796
We're trying to work out ...Stem's `test_take_ownership_via_controller` test fails when run in Travis CI. This is a recent failure, some time in the last month or two.
See, for example:
https://travis-ci.org/torproject/tor/jobs/639546796
We're trying to work out if it's a Tor or Stem issue right now, here's the corresponding Stem ticket:
https://github.com/torproject/stem/issues/52Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33005Lower log level of standard error messages from PT's2020-06-13T15:50:03ZAlexander Færøyahf@torproject.orgLower log level of standard error messages from PT'sWhile trying to reproduce #32034 I noticed we were logging messages sent from a PT on stderr with `warn` as log level, which is probably too high.
Already wrote a patch for it in #32034, but I need to update the changes file to use this...While trying to reproduce #32034 I noticed we were logging messages sent from a PT on stderr with `warn` as log level, which is probably too high.
Already wrote a patch for it in #32034, but I need to update the changes file to use this ticket ID.Tor: unspecifiedAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32994Get all flag defaults from port_cfg_new()2020-06-13T15:52:10ZteorGet 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/legacy/trac/-/issues/32984Revert #32883 for now and apply #32778 (so nt services can work in 0.4.3)2020-06-13T15:50:01ZNick MathewsonRevert #32883 for now and apply #32778 (so nt services can work in 0.4.3)In theory, #32883 was a better solution for the problem that #32778 was supposed to solve. In practice, it seems to break nt services on master. We should revert it for now until we have time to debug it in a later alpha series.In theory, #32883 was a better solution for the problem that #32778 was supposed to solve. In practice, it seems to break nt services on master. We should revert it for now until we have time to debug it in a later alpha series.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32971Document OwningControllerProcess time interval2020-06-13T15:50:00ZteorDocument OwningControllerProcess time intervalTor checks for its owning controller process every 15 seconds:
https://github.com/torproject/tor/blob/4f02812242d1fd90d859eb98ac3fb1ed182f18cf/src/lib/evloop/procmon.c#L168
We should document this interval in the man page.Tor checks for its owning controller process every 15 seconds:
https://github.com/torproject/tor/blob/4f02812242d1fd90d859eb98ac3fb1ed182f18cf/src/lib/evloop/procmon.c#L168
We should document this interval in the man page.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32962add_c_file: bug when adding to end of include.am2020-06-13T15:49:59ZNick Mathewsonadd_c_file: bug when adding to end of include.amTaylor reports that add_c_file behaves incorrectly when adding an item to the end of a list in an automake chunk.Taylor reports that add_c_file behaves incorrectly when adding an item to the end of a list in an automake chunk.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32961Backport the diagnostic logs for is_possible_guard crash2020-06-13T15:49:59ZteorBackport the diagnostic logs for is_possible_guard crashLet's backport this PR to diagnose the #32868 is_possible_guard crash:
* 0.3.5: https://github.com/torproject/tor/pull/1661Let's backport this PR to diagnose the #32868 is_possible_guard crash:
* 0.3.5: https://github.com/torproject/tor/pull/1661Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32960CID 1457825: stub version of nt_service_parse_options() makes coverity think ...2020-06-13T15:49:58ZNick MathewsonCID 1457825: stub version of nt_service_parse_options() makes coverity think we have dead code```
*** CID 1457825: Possible Control flow issues (DEADCODE)
/src/app/main/main.c: 1244 in tor_run_main()
1238 memcpy(argv + tor_cfg->argc, tor_cfg->argv_owned,
1239 tor_cfg->argc_owned*sizeof(char*));
1240 ...```
*** CID 1457825: Possible Control flow issues (DEADCODE)
/src/app/main/main.c: 1244 in tor_run_main()
1238 memcpy(argv + tor_cfg->argc, tor_cfg->argv_owned,
1239 tor_cfg->argc_owned*sizeof(char*));
1240
1241 int done = 0;
1242 result = nt_service_parse_options(argc, argv, &done);
1243 if (done)
>>> CID 1457825: Possible Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "goto done;".
1244 goto done;
1245
1246 pubsub_install();
1247
1248 {
1249 int init_rv = tor_init(argc, argv);
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32957Tor: remove support for the pre-0.3.5 directory structure2020-06-13T15:49:57ZteorTor: remove support for the pre-0.3.5 directory structureOur git scripts and some of our test scripts still support Tor's pre-0.3.5 directory structure.
Now that 0.2.9 is unsupported, we can remove this code.
We should be able to find it by grepping for "0.2.9", "029", "src/or", "src/common"...Our git scripts and some of our test scripts still support Tor's pre-0.3.5 directory structure.
Now that 0.2.9 is unsupported, we can remove this code.
We should be able to find it by grepping for "0.2.9", "029", "src/or", "src/common", "0.3.5", or "035".Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32955Update dir-spec for removing consensus methods 25-272020-06-13T15:49:57ZteorUpdate dir-spec for removing consensus methods 25-27We need a corresponding dir-spec change for #32695.We need a corresponding dir-spec change for #32695.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32954Stop public authorities specifying an internal address for their IPv6 ORPort2020-06-13T15:49:56ZteorStop public authorities specifying an internal address for their IPv6 ORPortWhen we implement `Address [IPv6]` in #30954, we should check that the supplied IPv6 address is a public address on Directory Authorities.
This matches the current `Address IPv4` check for authorities.When we implement `Address [IPv6]` in #30954, we should check that the supplied IPv6 address is a public address on Directory Authorities.
This matches the current `Address IPv4` check for authorities.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32944where are we still excessively strict about clock skew? pluggable transports?2020-06-13T15:49:55ZTaylor Yuwhere are we still excessively strict about clock skew? pluggable transports?Right now core tor should tolerate +/- 24 hours of clock skew. It seems like some pluggable transports are stricter. We should characterize these and possibly work on solutions if necessary.Right now core tor should tolerate +/- 24 hours of clock skew. It seems like some pluggable transports are stricter. We should characterize these and possibly work on solutions if necessary.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32943factor out supporting shell scripts from CI configs2020-06-13T15:49:55ZTaylor Yufactor out supporting shell scripts from CI configsWe should create some support shell scripts that factor out shared command sequences from our CI configs. This will make it easier to keep configurations for different CI platforms in sync.We should create some support shell scripts that factor out shared command sequences from our CI configs. This will make it easier to keep configurations for different CI platforms in sync.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32942Deprecate the ClientAutoIPv6ORPort option2020-06-13T15:49:55ZNeel Chauhanneel@neelc.orgDeprecate the ClientAutoIPv6ORPort optionTor: 0.4.3.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32929Tor Manual: Split Node options into their own subsection2020-06-13T15:49:54ZteorTor Manual: Split Node options into their own subsectionLet's put the client *Node* and GeoIPExcludeUnknown options in their own manpage section.
For context, see:
https://trac.torproject.org/projects/tor/ticket/32846#comment:11Let's put the client *Node* and GeoIPExcludeUnknown options in their own manpage section.
For context, see:
https://trac.torproject.org/projects/tor/ticket/32846#comment:11Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32928Tor Manual: Split Circuit Timeout options into their own subsection2020-06-13T15:49:53ZteorTor Manual: Split Circuit Timeout options into their own subsectionLet's put the *Circuit*Timeout options in their own manpage section.
For context, see:
https://trac.torproject.org/projects/tor/ticket/32846#comment:11Let's put the *Circuit*Timeout options in their own manpage section.
For context, see:
https://trac.torproject.org/projects/tor/ticket/32846#comment:11Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32921Code and script changes to run clang-format without breaking checkSpaces or c...2020-06-13T15:51:46ZNick MathewsonCode and script changes to run clang-format without breaking checkSpaces or coccinelleI've been working to make changes to our code and our scripts to improve our clang-format output. I think they are mature enough that we can merge them now.
I also think it may be time to merge a .clang-format file and a script to run ...I've been working to make changes to our code and our scripts to improve our clang-format output. I think they are mature enough that we can merge them now.
I also think it may be time to merge a .clang-format file and a script to run it. We'll want to tweak it a bunch before we actually run it on our code, but getting it into our version control will help us refine our way towards a reasonable target.
**Edited to clarify**: Neither the .clang-format file, the script, or the post-processing tool are meant to be a final version. This branch does not mean that our style choices are final. The goal here is just to land initial versions that we can start experimenting with.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32910trace: Add tracepoints and userspace tracer support2020-06-13T15:49:51ZDavid Gouletdgoulet@torproject.orgtrace: Add tracepoints and userspace tracer supportTor-dev email: https://lists.torproject.org/pipermail/tor-dev/2019-December/014111.html
These are what needs to be done but they sorta need to be together to make sense thus this one ticket:
a. Add a series of tracepoints in tor code b...Tor-dev email: https://lists.torproject.org/pipermail/tor-dev/2019-December/014111.html
These are what needs to be done but they sorta need to be together to make sense thus this one ticket:
a. Add a series of tracepoints in tor code base. I propose to start with circuit and cell level tracepoints for now.
b. Add USDT (User Statically-Defined Tracing) probes support which is used by SystemTap, DTrace and perf.
c. Add LTTng support which if enable also emits USDT.
d. Integrate all this to our build system.
About(d), the consensus among the network team is that it should NEVER be enabled in production and should be a configure switch.
I believe if we add on top a torrc option, it might not be that useful in the end considering the configure switch but mainly it will degrade performance since the check needs to be at runtime for every tracepoint.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32907Remove or_options_t dependencies from module config headers2020-06-13T15:49:50ZteorRemove or_options_t dependencies from module config headersThe following inline header functions depend on some members of or_options_t, which is a dependency we don't need:
* options_validate_dirauth_mode()
* options_validate_server_transport()
* options_validate_relay_mode()
And the dependency...The following inline header functions depend on some members of or_options_t, which is a dependency we don't need:
* options_validate_dirauth_mode()
* options_validate_server_transport()
* options_validate_relay_mode()
And the dependency only exists when the relay or dirauth modules are disabled.
Instead, we could put these functions in stub C files, which are only compiled when relay/dirauth mode is disabled.Tor: 0.4.4.x-finalNick MathewsonNick Mathewson