The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:04:53Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8083add "{??}" (or other suitable alternative) for specifying nodes2020-06-27T14:04:53ZTracadd "{??}" (or other suitable alternative) for specifying nodesCurrently, if the origin of the IP address of a particular node is unknown, either due to messed-up GeoIP database, or due to tor having to rely on an outdated copy, there is no way to specify these nodes and include them in various *Nod...Currently, if the origin of the IP address of a particular node is unknown, either due to messed-up GeoIP database, or due to tor having to rely on an outdated copy, there is no way to specify these nodes and include them in various *Nodes torrc options.
By adding something like the above option (or other similar syntax) this can be achieved.
**Trac**:
**Username**: mr-4Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/80817802 tweaks per code review2020-06-27T14:04:53ZAndrea 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/tpo/core/tor/-/issues/8080ExitNodes statement not honoured by tor2020-06-27T14:04:53ZTracExitNodes statement not honoured by torIf I have the following sequence in my torrc file:
StrictNodes 1
ExitNodes <single_exit_node_fingerprint>
ExcludeNodes <large_list>
My understanding is that Tor is supposed to only open (exit) circuits by using the ExitNode specified ab...If I have the following sequence in my torrc file:
StrictNodes 1
ExitNodes <single_exit_node_fingerprint>
ExcludeNodes <large_list>
My understanding is that Tor is supposed to only open (exit) circuits by using the ExitNode specified above, with the obvious caveat that the node in question is fully functional (otherwise I am bound to get a rather cryptic message as the one I submitted in Bug legacy/trac#7890).
That does not appear to happen though:
[circ] 16 BUILT (3): BridgeNode1->IntermediateNode1->ExitNodeAsSpecified
[circ] 15 BUILT (3): BridgeNode2->IntermediateNode2->ExitNodeAsSpecified
[circ] 14 BUILT (3): BridgeNode1->IntermediateNode3->ExitNodeAsSpecified
[circ] 13 BUILT (3): BridgeNode2->IntermediateNode2->ExitNodeAsSpecified
[circ] 12 BUILT (3): BridgeNode2->IntermediateNode3->ExitNodeAsSpecified
[circ] 11 BUILT (3): BridgeNode1->IntermediateNode4->xxx.xxx.xxx.xxx(GB)
[circ] 10 BUILT (3): BridgeNode1->IntermediateNode4->yyy.yyy.yyy.yyy(NL)
[circ] 9 BUILT (3): BridgeNode2->IntermediateNode1->ExitNodeAsSpecified
where "ExitNodeAsSpecified" is the IP address of the node fingerprint specified in my ExitNode statement, "BridgeNodeX" is the IP address of my entry bridges, "IntermediateNodeX" is the IP address of the intermediate nodes.
"xxx.xxx.xxx.xxx(GB)" and "yyy.yyy.yyy.yyy(NL)" are the (offending) IP addresses of exit nodes I have *not* specified anywhere in my torrc and did not expect tor to create/open/use exit node circuits involving these nodes.
**Trac**:
**Username**: mr-4https://gitlab.torproject.org/tpo/core/tor/-/issues/8069NNTP SSL broken?2020-06-27T14:04:53ZproperNNTP SSL broken?Two news servers [aioe.org](https://www.aioe.org/) and [gmane.org](https://lists.torproject.org/pipermail/tor-talk/2006-October/016511.html) are inaccessible over SSL. Plain connections (reading) functional.
Could be by chance, could be...Two news servers [aioe.org](https://www.aioe.org/) and [gmane.org](https://lists.torproject.org/pipermail/tor-talk/2006-October/016511.html) are inaccessible over SSL. Plain connections (reading) functional.
Could be by chance, could be configuration mistake on my side, could be broken by Tor or TorBirdy. I have no idea.Tor: unspecifiedNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8065Bug: src/or/connection_edge.c:649: connection_ap_expire_beginning: Assertion ...2020-06-27T14:04:53ZcypherpunksBug: src/or/connection_edge.c:649: connection_ap_expire_beginning: Assertion circ->purpose == CIRCUIT_PURPOSE_C_GENERAL failedTor client crashed with the following message :
```
[...] [notice] Tor 0.2.4.9-alpha-dev (git-ee421e68d5231e39) opening log file.
Jan 27 20:13:39.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up.
Jan 2...Tor client crashed with the following message :
```
[...] [notice] Tor 0.2.4.9-alpha-dev (git-ee421e68d5231e39) opening log file.
Jan 27 20:13:39.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up.
Jan 27 20:13:43.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up.
Jan 27 20:13:48.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit)
Jan 27 20:13:53.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit)
Jan 27 20:14:32.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit)
Jan 27 20:14:37.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit)
Jan 27 20:14:42.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit)
Jan 27 20:14:47.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit)
Jan 27 20:15:22.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit)
Jan 27 20:15:26.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit)
Jan 27 20:15:31.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit)
Jan 27 20:15:36.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit)
Jan 27 20:28:38.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit)
Jan 27 20:33:24.000 [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.
```Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8062We try to squeeze a two-byte version into a one-byte link_proto2020-06-27T14:04:53ZRoger DingledineWe try to squeeze a two-byte version into a one-byte link_proto```
int highest_supported_version = 0;
...
uint16_t v = ntohs(get_uint16(cp));
if (is_or_protocol_version_known(v) && v > highest_supported_version)
highest_supported_version = v;
...
chan->conn->link_proto = highest_su...```
int highest_supported_version = 0;
...
uint16_t v = ntohs(get_uint16(cp));
if (is_or_protocol_version_known(v) && v > highest_supported_version)
highest_supported_version = v;
...
chan->conn->link_proto = highest_supported_version;
```
But
```
uint8_t link_proto; /**< What protocol version are we using? 0 for
* "none negotiated yet." */
```
So these checks in channel_tls_process_versions_cell():
```
if (!highest_supported_version) {
...
} else if (highest_supported_version == 1) {
...
} else if (highest_supported_version < 3 &&
chan->conn->base_.state == OR_CONN_STATE_OR_HANDSHAKING_V3) {
...
} else if (highest_supported_version != 2 &&
chan->conn->base_.state == OR_CONN_STATE_OR_HANDSHAKING_V2) {
```
can all be bypassed by sending 0x0101 rather than 0x0001, etc.
Reported by bob from irc. He says there are triggerable asserts, but he didn't clarify which one.
See also legacy/trac#8059 for a nearby bug.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8059miscounting when parsing versions cell2020-06-27T14:04:54ZRoger Dingledinemiscounting when parsing versions cell```
const uint8_t *cp, *end;
...
for (cp = cell->payload; cp+1 < end; ++cp) {
uint16_t v = ntohs(get_uint16(cp));
```
So we count the payload one byte at a time, considering that byte plus the one after it?
```
The payload in a...```
const uint8_t *cp, *end;
...
for (cp = cell->payload; cp+1 < end; ++cp) {
uint16_t v = ntohs(get_uint16(cp));
```
So we count the payload one byte at a time, considering that byte plus the one after it?
```
The payload in a VERSIONS cell is a series of big-endian two-byte
integers.
```
That probably produces some weird behavior. Marking as 0.2.3 since I'm not sure yet what weird behavior.
Reported by bob from irc.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8051Broken check for empty "bridge-ips" line in validate_bridge_stats()2020-07-24T14:16:14ZGeorge KadianakisBroken check for empty "bridge-ips" line in validate_bridge_stats()`geoip_format_bridge_stats()` generates the `bridge-stats` file contents, and if `country_data` is NULL then it writes "bridge-ips \n" to the file.
Then when `validate_bridge_stats()` is called, if it can't find a populated `bridge-ips`...`geoip_format_bridge_stats()` generates the `bridge-stats` file contents, and if `country_data` is NULL then it writes "bridge-ips \n" to the file.
Then when `validate_bridge_stats()` is called, if it can't find a populated `bridge-ips` line it tries to match "bridge-ips\n", which should always fail because of the extra whitespace that was added in `geoip_format_bridge_stats()`. Isn't that right?
The only thing that confuses me is why this hasn't triggered so far. Maybe something in my analysis is incorrect, or the `bridge-stats` file is always generated after we accept a connection?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8045torspec: Make public bridges add obfsproxy stats to their extra-info descriptors2020-06-27T14:04:54ZGeorge Kadianakistorspec: Make public bridges add obfsproxy stats to their extra-info descriptorsThis ticket is for specifying the `bridge-transport` extra-info descriptor directive, as introduced by:
https://trac.torproject.org/projects/tor/ticket/5040#comment:2This ticket is for specifying the `bridge-transport` extra-info descriptor directive, as introduced by:
https://trac.torproject.org/projects/tor/ticket/5040#comment:2Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8042Reloaded md never be purged for platforms with unsigned time_t2020-06-27T14:04:54ZcypherpunksReloaded md never be purged for platforms with unsigned time_tmicrodesc_cache_reload() calls microdescs_add_to_cache() with listed_at == -1, so md->last_listed was defined by annotation loaded from disk only.
```
if (listed_at > 0) {
SMARTLIST_FOREACH(descriptors, microdesc_t *, md,
...microdesc_cache_reload() calls microdescs_add_to_cache() with listed_at == -1, so md->last_listed was defined by annotation loaded from disk only.
```
if (listed_at > 0) {
SMARTLIST_FOREACH(descriptors, microdesc_t *, md,
md->last_listed = listed_at);
```
But if unsigned time_t then last_listed updated to 0xFF..FF value so that md never be purged by microdesc_cache_clean(). If such md was flushed to disk during rebuild cache then it will forever live.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8037Specialy crafter microdesc could trigger to flush up to 16MB uninited heap al...2020-06-27T14:04:54ZcypherpunksSpecialy crafter microdesc could trigger to flush up to 16MB uninited heap allocated memory to mediamicrodescs_parse_from_string() and so on func do not count string as null terminated and allows to process "string" with zero byte in middle. md->body = tor_strndup(cp, md->bodylen) duplicate only partial of such string. dump_microdescri...microdescs_parse_from_string() and so on func do not count string as null terminated and allows to process "string" with zero byte in middle. md->body = tor_strndup(cp, md->bodylen) duplicate only partial of such string. dump_microdescriptor() flushes all bodylen of md's body to disk. Specially crafted bytes append to valid md sent by directory cache could lead to flush up to 16MB of memory data to media. Tor tries to clear sensitive data on free(), but some non cleared memory still no need to write in plain text to media.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8031Assertion fast_memeq(md->body, "onion-key", 9) failed;2020-06-27T14:04:54ZcypherpunksAssertion fast_memeq(md->body, "onion-key", 9) failed;I am running Tor v0.2.4.6-alpha (git-b13c6becc892d971) running on Linux with Libevent 1.4.13-stable and OpenSSL 0.9.8o.
The system is running i686 debian linux 2.6.38.2 with some grsec patches applied.
Tor crashed with the following me...I am running Tor v0.2.4.6-alpha (git-b13c6becc892d971) running on Linux with Libevent 1.4.13-stable and OpenSSL 0.9.8o.
The system is running i686 debian linux 2.6.38.2 with some grsec patches applied.
Tor crashed with the following message in the console:
==== console
[... cut... ] [notice] Opening Directory listener on 0.0.0.0:3128
src/or/microdesc.c:492 microdesc_cache_rebuild: Assertion
fast_memeq(md->body, "onion-key", 9) failed; aborting.
Aborted.
==== // end of console
==== /var/log/tor/log from just before:
Jan 17 23:44:09.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [50 similar message(s) suppressed in last 60 seconds]
Jan 17 23:45:09.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [184 similar message(s) suppressed in last 60 seconds]
Jan 17 23:46:09.000 [warn] Your computer i
==== // end of /var/log/tor/log (it ends abruptly)
The log is big (17M) and dates a year or so back.
Looking through it now, I discovered that it routinely complained about things such as:
====
Jan 04 09:04:31.000 [warn] Failing because we have 1016 connections already. Please raise your ulimit -n. [272740629 similar message(s) suppressed in last 21600 seconds]
Jan 04 09:48:12.000 [warn] Cannot seed RNG -- no entropy source found.
Jan 04 09:55:16.000 [warn] Couldn't open "/var/lib/tor2/state.tmp" (/var/lib/tor2/state) for writing: Too many open files
Jan 04 09:55:16.000 [warn] Unable to write state to file "/var/lib/tor2/state"; will try again later
====
This feels like mismanagement on my part, but the console didn't say anything about it, so I never checked the logs before. It was running in a chroot and I must have forgotten to give it read permission for the chrooted /dev/{u,}random.
I hope this has nothing to do with the bug, but maybe a new change request should be added to write messages like that on the console?
I am available on irc as "sadoper" if you need further information.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8024Tor Client : "circuit_package_relay_cell(): Bug: outgoing relay cell has n_c...2020-06-27T14:04:55ZcypherpunksTor Client : "circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL. Dropping"[notice] Tor 0.2.4.9-alpha-dev (git-ee421e68d5231e39) opening new log file.
...
[warn] circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL. Dropping.[notice] Tor 0.2.4.9-alpha-dev (git-ee421e68d5231e39) opening new log file.
...
[warn] circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL. Dropping.Tor: 0.2.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8018path-spec does not discuss guard rotation2020-06-27T14:04:55ZAaron Johnsonpath-spec does not discuss guard rotationIt is known (http://cacr.uwaterloo.ca/techreports/2012/cacr2012-11.pdf) that clients rotate their guard sets every 30-60 days (length randomly chosen). This behavior is not discussed in the path specification (torspec.git/path-spec.txt)....It is known (http://cacr.uwaterloo.ca/techreports/2012/cacr2012-11.pdf) that clients rotate their guard sets every 30-60 days (length randomly chosen). This behavior is not discussed in the path specification (torspec.git/path-spec.txt). This is important for users and researchers to understand security.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8014Reject the reference-implementation of curve25519 from donna in a more compre...2020-06-27T14:04:55ZTracReject the reference-implementation of curve25519 from donna in a more comprehensible way.during ./configure I get the following result:
[...]
checking whether we can use curve25519-donna-c64... no
checking whether we can use curve25519 from nacl... no
I do have nacl(-devel) installed on my machine. Closer inspection of conf...during ./configure I get the following result:
[...]
checking whether we can use curve25519-donna-c64... no
checking whether we can use curve25519 from nacl... no
I do have nacl(-devel) installed on my machine. Closer inspection of config.log tells me that conftest.c has "#include <crypto_scalarmult_curve25519.h>". That file is in /usr/include/nacl, so I had to add "-I/usr/include/nacl" for this particular error to pass.
That didn't work though as I am now getting "conftest.c:58:4: error: #error Hey, this is the reference implementation!". The conftest.c file itself has this:
#include <crypto_scalarmult_curve25519.h>
#ifdef crypto_scalarmult_curve25519_ref_BYTES
#error Hey, this is the reference implementation!
#endif
"crypto_scalarmult_curve25519_ref_BYTES" is indeed defined in /usr/include/nacl/crypto_scalarmult_curve25519.h, so how am I supposed to satisfy this test then?
**Trac**:
**Username**: mr-4Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8012tor current compile breakage "compat_libevent.c"2020-06-27T14:04:55ZTractor current compile breakage "compat_libevent.c"With NetBSD 5_Stable (i386), libevent-2.0.21,
tracking current tor.
Even after 'make clean' and autogen/configure...
I get:
CC src/common/compat_libevent.o
src/common/compat_libevent.c: In function 'tor_check_libevent_versio...With NetBSD 5_Stable (i386), libevent-2.0.21,
tracking current tor.
Even after 'make clean' and autogen/configure...
I get:
CC src/common/compat_libevent.o
src/common/compat_libevent.c: In function 'tor_check_libevent_version':
src/common/compat_libevent.c:424: error: 'version' undeclared (first use in this function)
src/common/compat_libevent.c:424: error: (Each undeclared identifier is reported only once
src/common/compat_libevent.c:424: error: for each function it appears in.)
*** Error code 1
Stop.
Unable to continue...
**Trac**:
**Username**: yancmTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8002Mis-count of CPUs2020-06-27T14:04:55ZTracMis-count of CPUsOn start-up Tor v0.2.3.25/Linux says:
"[notice] Wow! I detected that you have 64 CPUs. I will not autodetect any more than 16, though. If you want to configure more, set NumCPUs in your torrc"
This is in a CentOS6/OpenVZ VPS with onl...On start-up Tor v0.2.3.25/Linux says:
"[notice] Wow! I detected that you have 64 CPUs. I will not autodetect any more than 16, though. If you want to configure more, set NumCPUs in your torrc"
This is in a CentOS6/OpenVZ VPS with only a single virtual CPU. Tor config param NumCPUs is not used.
It turns out that OpenVZ, since version rhel6/042stab061.2, lists all the *host* CPUs in /sys/devices/system/cpu/. It is this number of processors that is returned by the sysconf(_SC_NPROCESSORS_CONF) that Tor uses in ~/tor-0.2.3.25/src/common/compat.c to determine CPU count.
From the command line:
# getconf _NPROCESSORS_ONLN
1
Programmatically:
$ /tmp/main
sysconf() says: 64
Wow, too many CPUs: 64
I know that there's not much you can do about a sysconf() that lies. I want to get this on the record, though, for the sake of Tor's future auto-scaling.
**Trac**:
**Username**: tmpname0901Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8001obfsproxy makes tor warn when one bridge is down2022-05-23T20:31:06ZRoger Dingledineobfsproxy makes tor warn when one bridge is downWhen you run the fancy new flashproxy/obfsproxy bundle:
https://blog.torproject.org/blog/combined-flash-proxy-pyobfsproxy-browser-bundles
you get
```
Jan 19 15:09:17.120 [Warning] Proxy Client: unable to connect to 208.79.90.242:55564 ("...When you run the fancy new flashproxy/obfsproxy bundle:
https://blog.torproject.org/blog/combined-flash-proxy-pyobfsproxy-browser-bundles
you get
```
Jan 19 15:09:17.120 [Warning] Proxy Client: unable to connect to 208.79.90.242:55564 ("server rejected connection")
```
That's because that bridge is down currently.
When a bridge fails, we should probably only [warn] if no bridges have succeeded.https://gitlab.torproject.org/tpo/core/tor/-/issues/7986Lengthen the consensus validity interval2022-03-22T13:28:39ZNick MathewsonLengthen the consensus validity intervalRight now, the 24 hour "build a consensus in this interval or die horribly" time is chosen completely arbitrarily. I know of no reason to not allow 48 or 72 hours.
See comments on legacy/trac#2681 for more discussion of this point. Th...Right now, the 24 hour "build a consensus in this interval or die horribly" time is chosen completely arbitrarily. I know of no reason to not allow 48 or 72 hours.
See comments on legacy/trac#2681 for more discussion of this point. There's some discussion there of choosing an optimal time, but I suggest we just have some clients try 48 or 72 hours and see how it goes.
I'm boldly going with 72.
cc'ing arma because he remembers where the pain points are on the directory info download food chain, and mike because he has felt the pain.https://gitlab.torproject.org/tpo/core/tor/-/issues/7983TOR stuck in 25% Loading Network Stats Consensus2020-06-27T14:04:56ZTracTOR stuck in 25% Loading Network Stats ConsensusIm helping a friend to connect to TOR network in IRAN/Tehran. It used to be working just yesterday . But today seems it is stuck in this
step according to the LOG Files:
25% Loading Network Stats Consensus
according to TOR's Status:
...Im helping a friend to connect to TOR network in IRAN/Tehran. It used to be working just yesterday . But today seems it is stuck in this
step according to the LOG Files:
25% Loading Network Stats Consensus
according to TOR's Status:
Loading Network Status
is there any way to solve this problem ?
**Trac**:
**Username**: jam_hooTor: unspecified