[tor-bugs] #2511 [Tor Client]: Tor will use an unconfigured bridge if it was a configured bridge last time you ran Tor
Tor Bug Tracker & Wiki
torproject-admin at torproject.org
Thu Feb 10 04:55:05 UTC 2011
#2511: Tor will use an unconfigured bridge if it was a configured bridge last time
you ran Tor
-------------------------+--------------------------------------------------
Reporter: arma | Owner:
Type: defect | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.2.x-final
Component: Tor Client | Version:
Keywords: | Parent:
Points: | Actualpointsdone:
Pointsdone: | Actualpoints:
-------------------------+--------------------------------------------------
Comment(by arma):
Replying to [comment:5 nickm]:
> Will this break bridge authorities?
Yes! Good catch. We'll want to either check if UseBridges, or if
authdir_mode_bridge(). I don't have an opinion on which one we should
check.
> I personally don't like the approach of mucking up
router_add_to_routerlist even more: it's too hairy by half as is, and we
should be looking for ways to make it dumber, not smarter. Option 3 (or a
variant option 1 where instead of calling the bridge Down we call it
"Invalid" or something) seems much better.
Hm. Well, Option 3 was "do this patch and also add another patch
elsewhere", so I don't see how that will simplify
router_add_to_routerlist(). The real issue is that we have a growing set
of reasons why we wouldn't want to keep a router desc that we just learned
about. One way to simplify is to stop having so many reasons, but I don't
see a good way around that. What are some other ways to simplify? We could
break the checks out into several functions based on topic. Is there
another place in the code that we should be doing these checks instead?
Hm.
Specifically, if we go with option 1 and we want to handle bug2510, we're
going to need some messier special-casing either in
router_add_to_routerlist() or elsewhere that says "if we have a bridge
descriptor and we just got a descriptor that's the same as it but actually
we got it from this other address then we want to drop the old one so we
don't drop the new one before we can rewrite it". Maybe that means we
should be thinking about bug 2510 in parallel to this one, not after.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2511#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list