#21415: tor_bug_occurred_: Bug: src/or/entrynodes.c:1845:
select_entry_guard_for_circuit: Non-fatal assertion
!(!guard_has_descriptor(guard)) failed.
-----------------------------+------------------------------------
 Reporter:  cypherpunks      |          Owner:  nickm
     Type:  defect           |         Status:  needs_review
 Priority:  Medium           |      Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor     |        Version:  Tor: 0.3.0.3-alpha
 Severity:  Normal           |     Resolution:
 Keywords:  review-group-16  |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:  asn              |        Sponsor:
-----------------------------+------------------------------------

Comment (by asn):

 Replying to [comment:25 nickm]:
 > The get_configured_bridge_by_exact_addr_port_digest() change looks safe.
 >
 > For the learned_router_identity change -- is there some way we might
 have changed the addr:port arguments to that function before we call it,
 and they might not be the same as the bridge line any more?  I know there
 are some weird cases with connection addresses in the code, but I'm not
 sure if they apply to bridges.
 >

 Yes that's a good point and we should be careful.

 I used the `make -k` trick and I audited the places that could be
 rewriting the addrport of a connection but I didn't find anything relevant
 for this case...

 As an example, `connection_or_check_canonicity()` does a pretty sneaky
 rewrite, but it only seems to happen for ORs and in our case we are a
 client using bridges.

 For an alternative confidence-inspiring obsevation, notice that in
 `learned_router_identity()` (the function we modded), a bit after we call
 `get_configured_bridge_by_exact_addr_port_digest()` we call
 `find_transport_name_by_bridge_addrport()` which does a very similar
 operation as the `_exact_` function; namely it walks through the bridges
 and compares their addrport with the conn addrport. So if
 `find_transport_name_by_bridge_addrport()` is trusting the connection
 addrport and the code has been working for a while, it seems to be an
 argument that our modification is also innocuous.

 > General note -- this branch is based on master.  When you're writing a
 branch to go into 0.3.0, it's a little easier for me if you base the
 branch on maint-0.3.0 instead of on master.  "git worktree" can make this
 really convenient, and let you have separate directories for each branch
 you're working on.

 Oops yes, sorry about that. I need to take some time and learn how to use
 `git worktree`. Last time I spent 10 minutes but didn't manage to grasp it
 completely. Will try to do this soon.

 Let me know if you want me to rebase the branch to 0.3.0.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21415#comment:26>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Reply via email to