The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-09-16T14:36:00Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8111Refactor our checking of whether we should be reading/writing on a connection...2021-09-16T14:36:00ZNick MathewsonRefactor our checking of whether we should be reading/writing on a connection to use a set of reason-flagsThere are plenty of things that can block reading or writing on a connection: being out of bandwidth, not having anything more to say, having an internal buffer get too full, etc.
There are too many places where one of the things that w...There are plenty of things that can block reading or writing on a connection: being out of bandwidth, not having anything more to say, having an internal buffer get too full, etc.
There are too many places where one of the things that would block read/write becomes false, and so we check all of the *other* potential reasons not to read/write before we re-enable reading/writing.
There's a much better pattern we could use: have a flags variable for "read_blocked" and a flags variable for "write_blocked", each bit of which represents a reason not to be reading or writing. Instead of calling connection_{stop,start}_{reading,writing} directly, we would call {un,}block_{reading,writing}(conn, reason), which would set or clear a bit corresponding to 'reason', and block/unblock reading/writing accordingly.
I haven't yet verified that this is a win; we should audit all the uses of connection_{stop,start}_{reading,writing} reading to see.https://gitlab.torproject.org/tpo/core/tor/-/issues/8109Use -fomit-frame-pointer with curve25519_donna.c2020-06-27T14:04:52ZNick MathewsonUse -fomit-frame-pointer with curve25519_donna.cGiving the compiler an extra register to work with can make our handshake run about 6% faster on register-starved 32-bit systems without nacl.Giving the compiler an extra register to work with can make our handshake run about 6% faster on register-starved 32-bit systems without nacl.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8108Implement IncludeFile (or similar) directive in torrc2020-06-27T14:04:52ZTracImplement IncludeFile (or similar) directive in torrcUse case: I have multiple torrcX configurations (X=1,2...) and instead of duplicating quite a few torrc options in all those files, it would be better if I could have IncludeFile (or similar) directive to ask tor to parse the extra file ...Use case: I have multiple torrcX configurations (X=1,2...) and instead of duplicating quite a few torrc options in all those files, it would be better if I could have IncludeFile (or similar) directive to ask tor to parse the extra file and include the options listed there at the point where they are specified. For example:
torrc1 (present day)
====================
SocksPolicy accept 127.0.0.1:*
SocksPolicy accept 127.0.0.28:*
[...]
SocksPort 9050
SocksListenAddress 127.0.0.1:9050
SocksPolicy accept 10.0.1.0/24:*
SocksPolicy accept 10.0.2.0/24:*
SocksPolicy accept 10.0.3.0/24:*
SocksPolicy accept 10.0.4.0/24:*
SocksPolicy reject *:*
ReachableAddresses *:9001, *:9090-9091
ExcludeNodes <large_list>
[...]
torrc2 (present day)
====================
[...]
SocksPort 9050
SocksListenAddress 127.0.0.1:9050
SocksPolicy accept 10.0.1.0/24:*
SocksPolicy accept 10.0.2.0/24:*
SocksPolicy accept 10.0.3.0/24:*
SocksPolicy accept 10.0.4.0/24:*
SocksPolicy reject *:*
ReachableAddresses *:9001, *:9090-9091
ExcludeNodes <large_list>
[...]
Note that the majority of Socks* options, as well as ReachableAddresses and ExcludeNodes are duplicated in both files. If I had the opportunity to use IncludeFile option, then I could do something like:
torrc.inc
=========
SocksPort 9050
SocksListenAddress 127.0.0.1:9050
SocksPolicy accept 10.0.1.0/24:*
SocksPolicy accept 10.0.2.0/24:*
SocksPolicy accept 10.0.3.0/24:*
SocksPolicy accept 10.0.4.0/24:*
SocksPolicy reject *:*
ReachableAddresses *:9001, *:9090-9091
ExcludeNodes <large_list>
torrc1
======
SocksPolicy accept 127.0.0.1:*
SocksPolicy accept 127.0.0.28:*
[...]
IncludeFile torrc.inc
[...]
torrc2
======
[...]
IncludeFile torrc.inc
[...]
In this case, if I need to change one of the "common" options all I have to do is change the torrc.inc file and not trash all my torrcX files and change each and every option in them.
That is particularly painful if I have to maintain a list of my ExcludeNodes for example.
Another useful "technique" in which the IncludeFile directive will be very handy is if some/all of the options listed in torrc.inc are auto-generated (building ExcludeNodes statement from parsing an updated version of a geoip database for example) - that way I don't even need to lift my finger and go through all my torrcX files and update those options and will just run the appropriate (shell) script to build torrc.inc and that will be that.
**Trac**:
**Username**: mr-4Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8107Rename tor_queue.h macros to start with TOR_2020-06-27T14:04:52ZNick MathewsonRename tor_queue.h macros to start with TOR_We haven't seen the last of legacy/trac#7293 : having our own sys/queue.h is a recipe for conflicts with system headers whenever theirs is included before ours, or ours is included before their headers. Instead, let's just rename all th...We haven't seen the last of legacy/trac#7293 : having our own sys/queue.h is a recipe for conflicts with system headers whenever theirs is included before ours, or ours is included before their headers. Instead, let's just rename all the macros in src/ext/tor_queue.h to begin with TOR_.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8106Make .onion addresses harder to harvest by directory servers2020-06-27T14:04:52ZGeorge KadianakisMake .onion addresses harder to harvest by directory serversCurrently, an `HSDir` can relax on the hash ring, receive descriptor lookups and harvest .onions for days. Furthermore, it doesn't even have to change identity keys, since its position on the hash ring changes every day (because of the t...Currently, an `HSDir` can relax on the hash ring, receive descriptor lookups and harvest .onions for days. Furthermore, it doesn't even have to change identity keys, since its position on the hash ring changes every day (because of the timestamp), so it gets new .onions all the time.
This ticket is for research on how we can make .onion addresses harder to harvest.
Proposal 143 has some ideas that will reduce the exposure of .onions, but it doesn't solve the problem itself.
On actual solutions, Robert posted:
https://lists.torproject.org/pipermail/tor-dev/2012-September/004026.html
some months ago. I don't have the cryptographic skills to robustly analyze his idea, but if this is the only thing we have, we should point some cryptographers at it so that it gets some comments.
I also seem to recall that there was a paper suggesting hidden services to create ephemeral .onion addresses or something, but after asking Karsten and crawling anonbib I'm not sure that such a paper exists.
Are there any other proposed solutions out there? If not, this might be a fun research problem.https://gitlab.torproject.org/tpo/core/tor/-/issues/8094Consensus methods 15 through 17 are undocumented2020-06-27T14:04:52ZKarsten LoesingConsensus methods 15 through 17 are undocumentedLooks like dir auths recently started supporting consensus methods 15 and 16, but there's nothing in dir-spec.txt.Looks like dir auths recently started supporting consensus methods 15 and 16, but there's nothing in dir-spec.txt.Tor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8093Jan 29 23:32:20.066 [Warning] Bug/attack: unexpected sendme cell from client....2020-06-27T14:04:52ZTracJan 29 23:32:20.066 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.Tor repeatedly logs the following warning to the log:
Jan 29 23:32:20.066 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
My tor client is transferring up to 1MB per second. To give you an idea of how frequent t...Tor repeatedly logs the following warning to the log:
Jan 29 23:32:20.066 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
My tor client is transferring up to 1MB per second. To give you an idea of how frequent the messages are, here is a sample from the log:
Jan 30 08:02:38.565 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:08:35.479 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:09:42.842 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:11:43.152 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:14:56.327 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:19:33.993 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:19:41.684 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:19:51.278 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:20:46.170 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:22:21.517 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:24:21.550 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:26:02.562 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:26:03.966 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:26:28.745 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:27:57.262 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:28:20.702 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:31:24.491 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:32:31.640 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:33:11.243 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:33:25.613 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:35:20.153 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:36:14.547 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:36:19.196 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:37:26.787 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:37:32.013 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:37:54.571 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:38:24.782 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:48:50.658 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
Jan 30 08:50:09.286 [Warning] Bug/attack: unexpected sendme cell from client. Closing circ.
**Trac**:
**Username**: GravitasTor: unspecifiedNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8084tests suite failure2020-06-27T14:04:52Zcypherpunkstests suite failureTor git-123daffb600cb1b5
```
geoip:
FAIL src/test/test.c:1734: assert((dirreq_stats_1) == (s)): <dirreq-stats-end 2010-08-12 13:27:30 (86400 s)
```Tor git-123daffb600cb1b5
```
geoip:
FAIL src/test/test.c:1734: assert((dirreq_stats_1) == (s)): <dirreq-stats-end 2010-08-12 13:27:30 (86400 s)
```Tor: 0.2.4.x-finalhttps://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-final