Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:25:45Zhttps://gitlab.torproject.org/legacy/trac/-/issues/7157"Low circuit success rate %u/%u for guard %s=%s."2020-06-13T14:25:45ZRoger Dingledine"Low circuit success rate %u/%u for guard %s=%s."I'm seeing this "low circuit success rate" warning on my client sometimes when on a flaky wireless network connection.
I'm guessing that the problem is that we're blaming the guard when we should in fact be blaming the network.
We shou...I'm seeing this "low circuit success rate" warning on my client sometimes when on a flaky wireless network connection.
I'm guessing that the problem is that we're blaming the guard when we should in fact be blaming the network.
We should a) figure out how to improve the log message so we get more hints about where our bug is, and/or b) just straight-out hunt for it.
Mike suggests raising the number of circuits we have to make before we'll spit out the warning. I expect that will mask the bug, but not find or resolve it.
Bug report originally raised in #7066.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9366"ORPort ... Noadvertise" means your bridge silently doesn't work2020-06-13T14:36:15ZRoger Dingledine"ORPort ... Noadvertise" means your bridge silently doesn't workIf you set up a bridge with
```
bridgerelay 1
orport 9509 noadvertise
```
and then have somebody try to reach it with a client (usebridges 1 bridge x.y.z.a:9509).
The result is that the client will stop bootstrapping at
```
Jul 31 16:0...If you set up a bridge with
```
bridgerelay 1
orport 9509 noadvertise
```
and then have somebody try to reach it with a client (usebridges 1 bridge x.y.z.a:9509).
The result is that the client will stop bootstrapping at
```
Jul 31 16:06:09.990 [notice] Bootstrapped 50%: Loading relay descriptors.
Jul 31 16:06:10.752 [notice] no known bridge descriptors running yet; stalling
```
What's happening is the client is asking for /tor/server/authority.z, and on the bridge side, directory_handle_command_get() calls dirserv_get_routerdesc_fingerprints() which calls router_get_my_routerinfo() which returns NULL.
I assume that's because router_rebuild_descriptor() calls router_get_advertised_or_port() which calls get_first_advertised_port_by_type_af() which checks !cfg->no_advertise and ends up returning 0.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6872'bwweightscale' pram missing from spec2020-06-13T14:22:52ZDamian Johnson'bwweightscale' pram missing from specThe 'bandwidth-weights' attribute mentions that its values are divided by the 'bwweightscale' param which defaults to 10000 (I'm not sure what meaning "BW_WEIGHT_SCALE" has - guess it's the name of the constant in tor's codebase?)...
ht...The 'bandwidth-weights' attribute mentions that its values are divided by the 'bwweightscale' param which defaults to 10000 (I'm not sure what meaning "BW_WEIGHT_SCALE" has - guess it's the name of the constant in tor's codebase?)...
https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1482
The network status document's "params" section should include 'bwweightscale' and the default value.
https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1228
On a side note it's pointless for 'bandwidth-weights' to say that the entries are sorted. The above shows the order that entries must appear in.
I'm assuming that new "Wxx=" values are invalid since the spec explicitly lists what it contains and makes no allowances for new ones. If this is incorrect then we should fix that too.
Cheers! -DamianTor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/8136(CRASH) "Bug: outgoing relay cell has n_chan==NULL"2020-06-13T14:27:01Zcypherpunks(CRASH) "Bug: outgoing relay cell has n_chan==NULL"17:37:33 [ARM_NOTICE] Tor control port closed
17:37:33 [ERR] connection_ap_expire_beginning(): Bug: src/or/connection_edge.c:649: connection_ap_expire_beginning: Assertion circ->purpose == CIRCUIT_PURPOSE_C_GENERAL failed; aborting.
17:3...17:37:33 [ARM_NOTICE] Tor control port closed
17:37:33 [ERR] connection_ap_expire_beginning(): Bug: src/or/connection_edge.c:649: connection_ap_expire_beginning: Assertion circ->purpose == CIRCUIT_PURPOSE_C_GENERAL failed; aborting.
17:37:26 [WARN] circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL. Dropping.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4664./autogen.sh puts stuff on stderr2020-06-13T14:15:49ZSebastian Hahn./autogen.sh puts stuff on stderrinside autogen.sh, we call autoreconf -ivf. The -v flag means verbose reports, which are basically just "going to dir x, calling application y" on stderr. This is pretty useless, and for some scripts I'd like to be able to silence the ou...inside autogen.sh, we call autoreconf -ivf. The -v flag means verbose reports, which are basically just "going to dir x, calling application y" on stderr. This is pretty useless, and for some scripts I'd like to be able to silence the output except for error conditions. Can we simply take out the -v here without bad stuff happening?Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6599./configure script using option -q2020-06-13T14:21:51ZTrac./configure script using option -qThe configure script is not quiet when using the option -q.
# ./configure --prefix=/ -q
tor_cv_library_openssl_dir is (system)
#
OS: OpenBSD 5.1
**Trac**:
**Username**: tgredemarkThe configure script is not quiet when using the option -q.
# ./configure --prefix=/ -q
tor_cv_library_openssl_dir is (system)
#
OS: OpenBSD 5.1
**Trac**:
**Username**: tgredemarkTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/80817802 tweaks per code review2020-06-13T15:29:47ZAndrea Shepard7802 tweaks per code review7802 accidentally got merged with 8024 before being reviewed; joint code review by nickm and myself followed. Nothing so objectionable as to merit reverting the merge, but a few points noted (full IRC transcript will be attached):
18:4...7802 accidentally got merged with 8024 before being reviewed; joint code review by nickm and myself followed. Nothing so objectionable as to merit reverting the merge, but a few points noted (full IRC transcript will be attached):
18:45 < athena> okay, in circuitbuild.c we've got some pretty straightforward functions to query parameters that look
just fine, then a long block of code which is probably where we should be focusing most attention
18:45 < nickm> Right. The "rate" configuration things are all percentages, but I don't see anything that keeps you from
configuring a value below zero or above 100 in config.c. We should note that. NOTE.
18:45 < nickm> (I'm going to grep for NOTE strings.)
18:45 < athena> okay, yeah, those should be checked and clamped, i think
***
18:48 < nickm> I don't like the name "pathbias_check_use_rate" -- "check" is pretty vague. NOTE.
18:48 < nickm> The return; at the end of that function offends me. NOTE.
18:48 < athena> yeah
18:49 < nickm> I think the comment for the next function (pathbias_mark_use_success) may be wrong; the "stat" in the
first sentence should probably be 'state'. and the word "mark" should appear before "it".
18:49 < nickm> NOTE.
***
18:53 < nickm> ooh. In mark_use_success, we check path_state < PATH_STATE_USE_ATTEMPTED. We should make sure that a
comment on path_state_t says that its values must never be reordered or else stuff might break. NOTE
18:54 < athena> did you mean to say pathbias_should_count? i'm not seeing a pathbias_should_close
18:54 < nickm> sorry, should_count
18:55 < athena> okay
18:55 < athena> looks like it ignores circuits that have some purposes, that are one-hop or checks some config options
18:55 < athena> do circuit purposes ever change during the lifetime of a circuit
18:55 < athena> ?
18:56 < nickm> I believe circuit purposes can change under some circumstances, though the rules are nontrivial
18:56 < athena> hmm
18:56 < nickm> maybe we should cache the result of this function if we've ever called it before?
18:56 < nickm> maybe we should warn if it changes?
18:57 < nickm> this isn't a new problem, if it's a problem
18:57 < athena> yeah, we need a detection for that if we can't be sure it doesn't happen
18:57 < nickm> NOTE. Let's ask mike?
***
19:04 < athena> well, the code moves the pathbias_send_usable_probe() to USE_ATTEMPTED; it seems nontrivial to evaluate
the effects of doing that
19:05 < athena> let's note that and move on, and ask mike about it when he's around
19:05 < nickm> right.
19:05 < athena> probably means we should settle on 'revert' for now if there's something like that in there that we
don't understand
19:06 < nickm> oh wait
19:06 < athena> ?
19:06 < nickm> read the description of 7802 again.
19:06 < nickm> he's splitting PATH_STATE_BUILD_SUCCEEDED into two states, where previously the distinction was not
based on state but based on timestamp_dirty
19:07 < athena> right
19:07 < athena> and the old probe did test timestamp_dirty
19:07 < athena> okay, this one's fine, then
19:07 < nickm> so that block that moved isn't the build_succeeded block; it's the build_succeeded && timestamp_dirty
block
19:07 < nickm> great
19:07 < nickm> and it now sets the state to ALREADY_COUNTED so we don't do this again. Sounds good.
19:08 < nickm> next two changes are function renames.
19:08 < athena> yeah
19:08 < nickm> Then the function now known as pathbias_get_close_success_count.
19:08 < nickm> Hm. path_state >= USE_FAILED and path_state >= BUILD_SUCCEEDED in the same function. I wish those were
macros or inline functions or something.
19:08 < nickm> NOTE above
19:09 < athena> yeah, making assumptions about enums like that always makes me feel icky
19:10 < nickm> (If you add a new value, you need to add it in the right position or there's hell to pay)
19:10 < athena> yeah\
19:11 < nickm> so the change in pathbias_get_closed_count is probably okay though I think.
19:12 < athena> yeah, agree
19:12 < nickm> agree?
19:12 < nickm> great
***
19:18 < nickm> pathbias_act_on_failure_rate?
19:18 < nickm> It doesn't return a boolean; it just messes with stuff and acts accordingly
19:18 < athena> it does, though
19:18 < nickm> oh, it does?
19:18 < athena> it returns -1 if it rejects the guard for a high failure rate
19:18 < nickm> Do we ever look at its return value?
19:18 < athena> or falls to the return 0 at the bottom of the function otherwise
19:18 < athena> dunno
19:19 < nickm> Looks like we call it in 2 places, and never check the return value there.
19:19 < athena> doesn't look like it
19:19 < athena> yeah, your suggestion then
19:19 < nickm> ok. NOTE let;s rename it to pathbias_act_on_failure_rate.
19:20 < athena> should we also get rid of the return value?
19:20 < nickm> Also NOTE that in the case where it sets any persistent value on a guard, it does need to call
entry_guards_changed I think
19:20 < nickm> yes we should. (NOTE)
***
19:21 < nickm> Hm. In the later part of the function that does scaling...
19:22 < nickm> ah, never mind.
19:22 < nickm> that looks okay to me if it does to you, since guard->use_{successes,attempts} are doubles.
19:23 < athena> yeah
19:23 < athena> it's just using a slightly awkward way of passing a rational
19:23 < nickm> We should check whether we enforce that scale_factor is at least 1, and mult_factor is less than or
equal to scale_factor.
19:23 < athena> but i'm not sure why, since if those are doubles we're already using floating point anyway
19:23 < athena> could just be a single function returning another double?
19:23 < nickm> (NOTE)
19:23 < nickm> I think it should be.
19:24 < nickm> I think he's doing it this way because consensus parameters can only be ints
19:24 < nickm> (int32_t, I think)
19:24 < athena> also make sure that we never divide by zero
19:24 < athena> oh, right
19:24 < nickm> Right. (NOTE wrt the refactoring though)
19:24 < athena> so it'd just be a pain to extend that to allow double, then
19:25 < nickm> yeah, but we can have the function return a double, and let the user configure a double themselves if
they want to override it in torrc
19:25 < nickm> (It would be crazy to override the numerator but not the denominator)
19:25 < athena> yeah
19:26 < athena> agreed; should be one function calculating the ratio of two int32_t consensus params *or* pulling a
double out of the config file
19:26 < nickm> Right. Let's do it like that. NOTE
***
19:26 < nickm> on to pathbias_check_close_rate. That should probably get renamed too.
19:27 < athena> pathbias_act_on_close_rate?
19:27 < nickm> yeah. That one _does_ have its return value checked.
19:27 < nickm> (lots of duplicate code here too I think)
19:27 < nickm> Does this look like duplicate code to you? Does a later commit fix that?
19:28 < athena> hold on, lemme look
19:29 < athena> yeah, it's kinda duplicated
19:29 < athena> but it's calling different functions in the log messages (get_use_success_count() vs.
get_close_success_count())
19:30 < athena> getting rid of the duplication would mean passing some function pointers around, probably
19:30 < athena> and i'm not sure where it gets scale_factor from
19:31 < nickm> Or having one block at the top of the function that says if (counting_closed) {
success_count=get_close_success_count() } else {success_count=get_use_success_count();} and avoid the
function pointers
19:31 < athena> yeah, okay
19:31 < athena> then should refactor to have less duplicate code i think
19:32 < nickm> The scaling block is pretty different
19:32 < nickm> isn't scale_factor coming from pathbias_get_scale_factor ?
19:32 < athena> hmm
19:32 < nickm> I hope everything scaled in that block is also a double, or our idea of having one function that returns
a double is going to break.
19:33 < athena> yeah
19:34 < athena> well, we could split the scaling out into separate rescale_<use,close> functions, and handle them like
the success_count thing?
19:35 < nickm> Seems good. Also Given that there are two sets of values that get scaled independently, we should make
sure that their documentation says which block is which, clearly.
19:35 < nickm> NOTE on the refactor and NOTE on the documentation
***
19:41 < nickm> I don't like the check on the return value of pathbias_check_close_rate(). That function only returns
-1 the first time it decides to disable the guard, right?
19:41 < nickm> maybe it should call it, then check whether guard->path_bias_disabled is true? (NOTE)
***
19:45 < nickm> Hm. I wonder what initializes node->use_attempts and node->use_successes and the other doubles if this
part isn't called.
19:46 < nickm> If they all come from a malloc_zero() or a memset, that's a little tricky. Does memset(&dbl, 0,
sizeof(double)) get you a good zero?
19:46 < athena> not on things that aren't IEEE-754 in general
19:47 < nickm> hm. we proably have other places where we do this.
19:47 < athena> yeah
19:47 < athena> it is theoretically a portability issue, but it's gotta be pretty rare to run into a machine like that
19:48 < athena> the only examples of non-754 fp i can think of off-hand are VAX and some older crays
19:48 < nickm> We could treat it like systems where memset(&ptr, 0, sizeof(void*)) doesn't set ptr to NULL.
19:48 < athena> yeah
19:48 < nickm> NOTE. let's do that.
***
19:57 < nickm> athena: this code looks okay to me, but I wonder if it wouldn't be better to change the check to call
one of the pathbias_act_on_foo_rate() functions instead to eliminate duplicated code. What do you think?
19:58 < athena> probably
19:59 < nickm> athena: I think this one isn't super-urgent, but we should still NOTE it. agree?
***
20:06 < athena> 24b9b9f791defcb6156c587a035fde58c35a46d9 next?
20:06 < nickm> yes let's
20:07 < nickm> The two blocks look duplicated, but there are only two
20:08 < athena> yeah
20:08 < athena> it could still be made into two calls to a single duplication-free function, though
20:08 < nickm> agreed.
20:08 < nickm> NOTE
20:08 < athena> a2db17a1aab77c4183f589815800a779a5f24524 ?
20:08 < nickm> hang on. So, if even one stream is detached, we roll back to USE_ATTEMPTED?
20:09 < nickm> What if there are multiple streams and only one is detached?
20:09 < nickm> It doesn't seem too harmful, but we should ask mike IMO.
20:09 < athena> hmm
20:09 < athena> yeah
20:09 < nickm> NOTE let's ask him
***
20:11 < nickm> a2db17a1aab77c4183 ?
20:11 < athena> yeah
20:14 < nickm> doesn't seem crazy. I don't get it though.
20:14 < nickm> I wonder if the comment in circuit_launch_by_extend_info before the line that's being removed is now inaccurate. NOTE
***
20:21 < nickm> so, the next commit does the common code refactoring you mentioned before when it adds
pathbias_count_circs_in_states
20:22 < nickm> also NOTE that the pairs of arguments to pathbias_count_circs_in_states are good things to document in
the documentation for path_state_t
20:22 < athena> yeah, agree
20:22 < nickm> As for the part of this change that changes how scaling happens... how does that look to you?
20:24 < athena> it looks correct to me
20:25 < nickm> I personally would kind of prefer it if we didn't add things to {circ,use}_{attempts,successes} until we
had the corresponding changes in the other scaled variables. then this commit wouldn't be needed.
that's a potentially bigger refactoring though. NOTE it for later?Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16248[Assertion] connection_stop_reading: Assertion conn->read_event failed; aborting2020-06-13T14:46:40Zyurivict271[Assertion] connection_stop_reading: Assertion conn->read_event failed; aborting<skipped>
> May 31 01:14:37.000 [notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $EC116BCB80565A408CE67F8EC3FE3B0B02C3A065~orion at 94.242.246.24. Retrying on a new circuit.
> May 31 01:14:37.000 [err] void tor_asse...<skipped>
> May 31 01:14:37.000 [notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $EC116BCB80565A408CE67F8EC3FE3B0B02C3A065~orion at 94.242.246.24. Retrying on a new circuit.
> May 31 01:14:37.000 [err] void tor_assertion_failed_(const char *, unsigned int, const char *, const char *)(): Bug: src/or/main.c:580: connection_stop_reading: Assertion conn->read_event failed; aborting.
> May 31 01:14:37.000 [err] Bug: Assertion conn->read_event failed in connection_stop_reading at src/or/main.c:580. (Stack trace not available)
This tor instance is only connected to the TransPort, with DNS to DNSPort.
I will be happy to provide any other information if I can.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6522[PATCH] Enable automake silent rules2020-06-13T14:21:40ZTrac[PATCH] Enable automake silent rulestwo patches to enable automake silent rules by default for build, including documentation builds (second patch).
This makes it easier to see compiler warnings.
As usual, it can be disabled with "make V=1" for any specific invocation of...two patches to enable automake silent rules by default for build, including documentation builds (second patch).
This makes it easier to see compiler warnings.
As usual, it can be disabled with "make V=1" for any specific invocation of make
**Trac**:
**Username**: stewartTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8448[Patch] FIx Typos2020-06-13T14:28:09ZTrac[Patch] FIx TyposFix some typos throughout the Tor branch and also improve one word from misformed to malformed (misformed does not seem the most appropriate)
**Trac**:
**Username**: bkerensa@ubuntu.comFix some typos throughout the Tor branch and also improve one word from misformed to malformed (misformed does not seem the most appropriate)
**Trac**:
**Username**: bkerensa@ubuntu.comTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6524[PATCH] move to non-recursive make2020-06-13T14:21:42ZTrac[PATCH] move to non-recursive makeThis patch switches the automake foo over to non-recursive make.
This gives us a few benefits:
1) make -j clean all
this will start working, as it should. It currently doesn't.
2) increased parallel build
r...This patch switches the automake foo over to non-recursive make.
This gives us a few benefits:
1) make -j clean all
this will start working, as it should. It currently doesn't.
2) increased parallel build
recursive make will max out at number of files in a directory,
non-recursive make doesn't have such a limitation
3) Removal of duplicate information in make files,
less error prone
I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way
that was used was not only deprecated but will be *removed* in the next
major automake release (1.13).... so probably best that we can continue
to bulid tor without requiring old automake.
(see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html )
For more reasons why, see resources such as:
http://miller.emu.id.au/pmiller/books/rmch/
Technically, this applies on top of the patches in https://trac.torproject.org/projects/tor/ticket/6522 - but they're probably not *required*
**Trac**:
**Username**: stewartTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9758AccountingMax == writes in 0.2.4.x?2020-06-13T14:32:02ZTracAccountingMax == writes in 0.2.4.x?My understanding is that what the AccountingMax setting matches against is traffic written. This seems reasonable for v0.2.3.x given that it writes slightly more than it reads.
My experience with v0.2.4.17 on multiple relays, though, i...My understanding is that what the AccountingMax setting matches against is traffic written. This seems reasonable for v0.2.3.x given that it writes slightly more than it reads.
My experience with v0.2.4.17 on multiple relays, though, is that more bytes are read than written, e.g.:
AccountingBytesReadInInterval 4523345070080
AccountingBytesWrittenInInterval 4398491181056
If AccountingMax is still compared to bytes written then we risk exceeding the user-specified maximum traffic per accounting period.
(Possibly these stats are influenced by the recent botnet activity.)
Note: I am setting the version number for this ticket as 0.2.4.16-rc because 0.2.4.17-rc is not available in the Version drop-down menu.
**Trac**:
**Username**: tmpname0901Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5178Adaptive circuit-build timeout code does not match spec2020-06-13T14:17:39ZRobert RansomAdaptive circuit-build timeout code does not match spec```
01:37 < rransom_> wanoskarnet: See section 2.4.4 of path-spec.txt in https://gitweb.torproject.org/torspec.git/tree . Does that match the behaviour in the code? Is that behaviour good?
01:43 < wanoskarnet> numbers are different. idea...```
01:37 < rransom_> wanoskarnet: See section 2.4.4 of path-spec.txt in https://gitweb.torproject.org/torspec.git/tree . Does that match the behaviour in the code? Is that behaviour good?
01:43 < wanoskarnet> numbers are different. idea is fine except definition of networkk connectivity loss. and no double the timeout can happen because it reset number of counts and could count abandoned circuit if counted of success circ.
01:44 < wanoskarnet> "was already 60 or higher" "or higher" actually means changed initial values only. but it's ok to check for such case.
01:46 < wanoskarnet> in oter work: code do reset timeout to init values but can't double timeout.
01:55 < wanoskarnet> circuit_build_times_network_check_live() non the same as "2.4.4". cbt->liveness.nonlive_timeouts incremeants just after "we've received no cells or TLS handshakes since those circuits began." no matter what number of timeouts.
01:57 < wanoskarnet> "if (cbt->liveness.nonlive_timeouts > 0)" should be 3?
```Tor: 0.2.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/4461Add a consensus parameter for token bucket refill interval2020-06-13T14:14:38ZKarsten LoesingAdd a consensus parameter for token bucket refill intervalWhen we merged the #3630 code, we changed the token bucket refill interval from 1/s to 10/s. We're now simulating whether this was a good choice in #4086.
Roger suggests that we add a consensus parameter that relays use to override the...When we merged the #3630 code, we changed the token bucket refill interval from 1/s to 10/s. We're now simulating whether this was a good choice in #4086.
Roger suggests that we add a consensus parameter that relays use to override their default token bucket refill interval. If we learn that 10/s wasn't the best choice, we can easily change it for all relays. Also, a consensus parameter would enable us to run experiments in the live Tor network, within reasonable bounds.
Thoughts?Tor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/7195Add a helpful warning log when a managed proxy dies during configuration2020-06-13T14:24:07ZGeorge KadianakisAdd a helpful warning log when a managed proxy dies during configurationIn `64b2a64310a66a3e22403917ecdef38263ba0483` I accidentally removed some warnings logs that helped users realize that their managed proxy died.
Let's add them back.In `64b2a64310a66a3e22403917ecdef38263ba0483` I accidentally removed some warnings logs that helped users realize that their managed proxy died.
Let's add them back.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6832Add a unit test of the offending tor_timegm() input2020-06-13T14:22:42ZGeorge KadianakisAdd a unit test of the offending tor_timegm() inputTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9147Add a warning when built with bufferevents2020-06-13T14:30:01ZNick MathewsonAdd a warning when built with buffereventsThere are more than a few bugs with the bufferevents IO backend. We should have Tor warn at startup when you've compiled Tor to use it.There are more than a few bugs with the bufferevents IO backend. We should have Tor warn at startup when you've compiled Tor to use it.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9866add anchors to the manpage2020-06-13T14:32:20Zweasel (Peter Palfrader)add anchors to the manpageIt would be nice if https://www.torproject.org/docs/tor-manual.html.en had anchors so we could link to specific config options.
I suspect adding the relevant anchors to our asciidoc tor manpage might make that happen.It would be nice if https://www.torproject.org/docs/tor-manual.html.en had anchors so we could link to specific config options.
I suspect adding the relevant anchors to our asciidoc tor manpage might make that happen.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6876Add config option OutboundBindAddressIPv62020-06-13T14:22:54ZLinus Nordberglinus@torproject.orgAdd config option OutboundBindAddressIPv6We need a way to specify an outbound IPv6 address.
Either we add OutboundBindAddressIPv6 or we start parsing
OutboundBindAddress when we read configuration and store two outbound
addresses, one for each supported address family.
I have...We need a way to specify an outbound IPv6 address.
Either we add OutboundBindAddressIPv6 or we start parsing
OutboundBindAddress when we read configuration and store two outbound
addresses, one for each supported address family.
I have implemented the OutboundBindAddressIPv6 alternative (because it
was easy). Let me know if we prefer the other one.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6406Add configuration option for directory authorities to vote on "a" lines2020-06-13T14:21:15ZLinus Nordberglinus@torproject.orgAdd configuration option for directory authorities to vote on "a" linesWhen deploying relays with IPv6 OR port(s) (#4564) we will want to
make it possible for directory authority operators to select if they
should vote on "a" lines or not. Add a configuration option,
AuthDirUseIPv6, indicating that a direc...When deploying relays with IPv6 OR port(s) (#4564) we will want to
make it possible for directory authority operators to select if they
should vote on "a" lines or not. Add a configuration option,
AuthDirUseIPv6, indicating that a directory authority should test OR
ports given in "or-address" lines in server descriptors and vote on
them. There might be a better name for the config option.
#5534 implements the testing and writing "a" lines to status
documents. This is done for bridge authorities only. That test
should be replaced with a test for the above mentioned config option.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.org