Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:54:29Zhttps://gitlab.torproject.org/legacy/trac/-/issues/18337Remove network dependencies from unit tests2020-06-13T14:54:29ZteorRemove network dependencies from unit testsSome of the new unit tests in 0.2.8 (#17076) seem to be using the resolver on non-existent addresses. This causes them to be slow when the network is up, but fast when it's down (at least on my OS X box).
mikeperry has also complained t...Some of the new unit tests in 0.2.8 (#17076) seem to be using the resolver on non-existent addresses. This causes them to be slow when the network is up, but fast when it's down (at least on my OS X box).
mikeperry has also complained that they're slow on IRC.
We could mock the address resolution functions to always return NXDOMAIN during these tests to make them faster.Tor: unspecifiedteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/17867Remove addresses and ports from dir_server_t and just use the ones in fake_st...2020-06-13T14:52:35ZteorRemove addresses and ports from dir_server_t and just use the ones in fake_statusWe put copies of an AuthDir / FallbackDir's addresses and ports in dir_server_t, and dir_server_t.fake_status. This is just asking for mistakes initialising them.
We could refactor the code so that we always use the addresses and ports ...We put copies of an AuthDir / FallbackDir's addresses and ports in dir_server_t, and dir_server_t.fake_status. This is just asking for mistakes initialising them.
We could refactor the code so that we always use the addresses and ports in fake_status.
This is not particularly urgent, because dir_server_t is read-only.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17081Improve coverage on src/common/sandbox.c2020-06-13T14:49:11ZTracImprove coverage on src/common/sandbox.cThe changes are in the branch "sandbox_tests"
https://github.com/twstrike/tor_for_patching/tree/sandbox_tests
**Trac**:
**Username**: rjuniorThe changes are in the branch "sandbox_tests"
https://github.com/twstrike/tor_for_patching/tree/sandbox_tests
**Trac**:
**Username**: rjuniorTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17036Report bandwidth more frequently in test networks2020-06-13T14:48:57ZteorReport bandwidth more frequently in test networksFor #16386 we need to reduce CHECK_DESCRIPTOR_INTERVAL and perhaps BANDWIDTH_RECHECK_INTERVAL in test networks. They should probably get a Testing* option and be defaulted to their current values (1 minute, 12 hours); but be ~4 seconds a...For #16386 we need to reduce CHECK_DESCRIPTOR_INTERVAL and perhaps BANDWIDTH_RECHECK_INTERVAL in test networks. They should probably get a Testing* option and be defaulted to their current values (1 minute, 12 hours); but be ~4 seconds and ~16 seconds by default (and configurable) in test networks.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17020Add test for Config options_act function2020-06-13T14:48:53ZTracAdd test for Config options_act functionIncrease test coverage for Config.c function options_act.
All changes are in following branch:
https://github.com/twstrike/tor/commit/eedfd46cb24f874b5608ee0c6ae49cabe832f97f
**Trac**:
**Username**: tcz001Increase test coverage for Config.c function options_act.
All changes are in following branch:
https://github.com/twstrike/tor/commit/eedfd46cb24f874b5608ee0c6ae49cabe832f97f
**Trac**:
**Username**: tcz001Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16849clear_status_flags_on_sybil might want to clear more flags2020-06-13T14:48:23Zteorclear_status_flags_on_sybil might want to clear more flagsclear_status_flags_on_sybil contains a comment saying "it's easy to add a new flag but forget to add it to this clause."
It looks like we may have forgot the following flags:
* is_hs_dir
* version_known?
* version_supports_extend2_cells...clear_status_flags_on_sybil contains a comment saying "it's easy to add a new flag but forget to add it to this clause."
It looks like we may have forgot the following flags:
* is_hs_dir
* version_known?
* version_supports_extend2_cells?
* has_bandwidth
* has_exitsummary?
* bw_is_unmeasured? (set to 1?)
* bandwidth_kb
* has_guardfraction
* guardfraction_percentage
To deal with the root cause, should we instead zero out the entire `routerstatus_t`, then copy the fields we need back in?
(This would zero new fields on sybils by default.)
We could also implement a unit test for clear_status_flags_on_sybil that checks that certain (important?) flags are cleared, or that all flags are cleared (?).Tor: unspecifiedffmanceraffmancerahttps://gitlab.torproject.org/legacy/trac/-/issues/16810Unit tests on circuit/relay functions2020-06-13T14:48:10ZNick MathewsonUnit tests on circuit/relay functionsWe have functions for maintaining, using, etc circuits and relay cells. These have almost no unit tests, and the fact makes me twitchy. We should remedy that.We have functions for maintaining, using, etc circuits and relay cells. These have almost no unit tests, and the fact makes me twitchy. We should remedy that.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16710Graph or plot test coverage over time?2020-06-13T14:47:49ZRoger DingledineGraph or plot test coverage over time?In reading our Sponsor S quarterly report draft, I found a section about how our unit test coverage is up to 37%, and our stem+chutney test coverage is up to 62%.
Great. What were they before, and what is their rate of change?
Is this ...In reading our Sponsor S quarterly report draft, I found a section about how our unit test coverage is up to 37%, and our stem+chutney test coverage is up to 62%.
Great. What were they before, and what is their rate of change?
Is this the sort of thing where we have the numbers somewhere? Is it easy to automate over time?
Ideally we should even arrange things so the graphs can help *us* in some way too -- first by e.g. giving somebody a sense of satisfaction when a big branch gets merged and the coverage line shoots up a lot, but then next by helping us notice when some *other* big branch gets merged that suddenly undermines coverage in a way we didn't expect? Let's not do this to satisfy a funder -- let's figure out a way where tracking and visualizing our progress helps us make progress better.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/14034Make TestingDirAuthVoteGuard/Exit/HSDir and AssumeReachable less essential in...2020-06-13T14:41:22ZteorMake TestingDirAuthVoteGuard/Exit/HSDir and AssumeReachable less essential in test networksCurrently, we need to use `TestingDirAuthVoteGuard *`, `TestingDirAuthVoteExit *`, and `AssumeReachable 1` to get a test network to bootstrap in under a minute. With #8243, we may need to create a `TestingDirAuthVoteHSDir *` option as we...Currently, we need to use `TestingDirAuthVoteGuard *`, `TestingDirAuthVoteExit *`, and `AssumeReachable 1` to get a test network to bootstrap in under a minute. With #8243, we may need to create a `TestingDirAuthVoteHSDir *` option as well.
These are rather blunt instruments to get boostrap working.
The changes in #13718 and (probably) #13929 ensure that testing networks bootstrap in 30s, without using `TestingDirAuthVoteExit *` or `AssumeReachable 1`. This provides a comprehensive method of testing network / exit bootstrap.
But it would be great to be able to test Guard/HSDir bootstrap too - perhaps by tweaking some settings in the chutney `torrc_templates`, or perhaps by fixing the implementation of one or more of tor's `Testing...` options (i.e. speeding up Guard/HSDir flag assignment in test networks).Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/13929Increase Authority reachability testing rate with low TestingAuthDirTimeToLea...2020-06-13T14:40:55ZteorIncrease Authority reachability testing rate with low TestingAuthDirTimeToLearnReachabilityIn a TestingTorNetwork, when TestingAuthDirTimeToLearnReachability is much lower than its normal value of 30 minutes, bootstrap will happen much more reliably if we test reachability at a proportionally faster rate.
I'd like to multiply...In a TestingTorNetwork, when TestingAuthDirTimeToLearnReachability is much lower than its normal value of 30 minutes, bootstrap will happen much more reliably if we test reachability at a proportionally faster rate.
I'd like to multiply the number of routers tested every 10 seconds, by the proportion that TestingAuthDirTimeToLearnReachability is smaller than the expected 1280 second cycle length.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/11146cov-diff utility should handle new source files2020-06-13T14:34:37ZNick Mathewsoncov-diff utility should handle new source filesRight now, cov-diff doesn't report coverage in source fils that are completely new. We should fix that.Right now, cov-diff doesn't report coverage in source fils that are completely new. We should fix that.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/11145coverage utility should merge multiple output files2020-06-13T14:34:36ZNick Mathewsoncoverage utility should merge multiple output filesWhen multiple gcov invocations generate output for the same file (typically a header), we should combine their results rather than letting the last invocation win.When multiple gcov invocations generate output for the same file (typically a header), we should combine their results rather than letting the last invocation win.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/10957Be more aggressive about enabling Extended ORPort2020-06-13T14:34:15ZGeorge KadianakisBe more aggressive about enabling Extended ORPortBridges without Extended ORPort do not publish statistics about usage. Some people really care about statistics.
In #9651 (merged in 0.2.5.1) we decided to add a warning if the user has PTs but no Extended ORPort.
Maybe we should be a ...Bridges without Extended ORPort do not publish statistics about usage. Some people really care about statistics.
In #9651 (merged in 0.2.5.1) we decided to add a warning if the user has PTs but no Extended ORPort.
Maybe we should be a bit more aggressive about enabling Extended ORPort, since many operators might simply ignore that warning.
Some solutions:
a) (Most aggressive) Just enable Extended ORPort by default if ORPort and PTs are in effect. Of course, make it listen only on localhost.
b) Turn the warning into an error, so that people can't start their bridge without it. The problem here is that it's not really an error, since the bridge will work fine without ExtORPort, but there will be no stats.
c) Use Unix sockets in platforms that support it; similar to how we do it for ControlPort.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/10817Write instructions for using valgrind with the debian tor2020-06-13T14:34:01ZRoger DingledineWrite instructions for using valgrind with the debian torIn #9754 we have a user experiencing weird heap corruption, or memory corruption, or who knows. It happened for a while and then it stopped happening.
If we'd had easier ways for normal Debian / Ubuntu users to run valgrind on their Tor...In #9754 we have a user experiencing weird heap corruption, or memory corruption, or who knows. It happened for a while and then it stopped happening.
If we'd had easier ways for normal Debian / Ubuntu users to run valgrind on their Tor, we might have gotten a more useful hint.
Also, we probably would have wanted it to be the Tor run the normal way, not a separate Tor run a different way.
Are there easy ways to do this? What's the right way to explain to a normal user how to do it?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/10186Backtrace support for windows2020-06-13T14:33:00ZNick MathewsonBacktrace support for windowsWith #9299, we added backtrace support for nearly all operating systems. Naturally, this doesn't include windows, because Windows Is Different.
We should use StackWalk64 to walk the stack, and we should use SetUnhandledException filtuer...With #9299, we added backtrace support for nearly all operating systems. Naturally, this doesn't include windows, because Windows Is Different.
We should use StackWalk64 to walk the stack, and we should use SetUnhandledException filtuer to detect crashes, or whatever the preferred mechanisms are.Tor: unspecifiedTom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/9957Tor should consider stderr output of transport proxies2020-06-13T14:35:38ZwfnTor should consider stderr output of transport proxiesCurrently, Tor cares about what transport proxies (e.g. obfsproxy) say over stdout (it echoes stdout in its log, etc.) Not so with stderr, the reason being, as far as I can tell, the presumed/standard signaling channel for transport prox...Currently, Tor cares about what transport proxies (e.g. obfsproxy) say over stdout (it echoes stdout in its log, etc.) Not so with stderr, the reason being, as far as I can tell, the presumed/standard signaling channel for transport proxies to communicate with Tor is their standard output stream, as per design.
It so happens that as of now, obfsproxy may complain about some things (e.g. it not being able to write to its own log file) over stderr. If one runs obfsproxy as intended (using the ServerTransportPlugin directive in torrc), obfsproxy may exit (Tor will report this, of course) without any verbal explanation.
Using the "run a transport proxy manually (without Tor) to figure out what's wrong" method (which some bridge operators have (had) to resort to (that is, at least me and someone else who talked with asn)) in order to debug things seems suboptimal.
Three ways out, as I see it:
1. Make sure all transport proxies adhere to the "use stdout to complain about things" protocol.
2. Have Tor treat both stdout and stderr streams of transport proxies as meaningful, and include their contents in log. This requires changing the design in regards to transport proxy <-> Tor signaling channels.
3. Care about stderr instead of stdout (most easy in terms of code changes, I think; not sure if makes much sense / is elegant, though.)
Are there any specific design-level nuances that block option 2?
For option 2, the [tor_get_lines_from_handle() function](https://gitweb.torproject.org/tor.git/blob/43f95e38abefced37ad24966d56298e972cebf81:/src/common/util.c#l4483) seems to be overall more or less handle-type-agnostic; it uses variable names like "stdout_buf", but it all really depends on what's passed via "handle", which could be any kind of stream.
[configure_proxy() in or/transports.c](https://gitweb.torproject.org/tor.git/blob/43f95e38abefced37ad24966d56298e972cebf81:/src/or/transports.c#l596) is what would need changing. Depending on design changes, the streams would have to be combined, or (simply) stderr would have to be used instead of stdout (so to remain clean, there'd need to be a tor_process_get_stderr_pipe(), which would simply `return process_handle->stderr_pipe`).Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6836Chop functionality out of routerlist.c2020-06-13T14:22:44ZNick MathewsonChop functionality out of routerlist.cIn my branch "split_routerlist.c", I have the start of some work on dividing routerlist.c into more sensible pieces. I've chopped out routerset_t, killed a couple of functions, and moved most of the node manipulation pieces into nodelis...In my branch "split_routerlist.c", I have the start of some work on dividing routerlist.c into more sensible pieces. I've chopped out routerset_t, killed a couple of functions, and moved most of the node manipulation pieces into nodelist.c
I'd still like to chop out more: the trusted_dir_server_t logic and the node-selection logic don't belong there any more. Nor does the authority certificate code. Nor does the hidden service directory stuff, nor does the hexdigest stuff.
In the longer term, I want routerlist.c to basically just not get invoked when you're not touching routerinfos.Tor: unspecifiedNick MathewsonNick Mathewson