bug with entry guards on 0.2.0.9-alpha

[tor user]

Greetings, 

I think I've found a bug with entry guard selection
starting with 0.2.0.9-alpha. The problem first appears
after revision 12038. 

My state file had 49 entry guards saved in it when I
happened to look earlier today. Thinking that was a
bit odd to have so many (it was only for the past
couple of months, and I don't use tor that often), I
did some testing to see what was happening. 

After poking at it a bit, starting with a clean ~/.tor
directory, it turned out that every time tor was
started, it would pick out more guards and add them.
The saved guards would always be marked as unlisted
initially (even if they weren't!), and new guards
would be used. 

It would build circuits with the new guards for a
while (about an hour) before noticing that the old
guards were actually up and switching back to using
them. That's probably not so good for anonymity. 

The behavior could be easily reproduced with default
settings. Each time tor was started and stopped, the
saved entry guard list would grow larger. 

Here's a snippet of a log file showing where tor is
failing to re-use entry guards that it saved on a
previous run only a few minutes earlier: 

Nov 19 20:45:03.730 [info] entry_guard_set_status():
Entry guard mehl
(13D31C1811B9A97FB2BE573E49543EAC668619AE) is
unlisted: marking as unusable.
Nov 19 20:45:03.730 [info]
entry_guards_compute_status(): Summary: Entry 'mehl'
is reachable, unusable and not live.
Nov 19 20:45:03.730 [info] entry_guard_set_status():
Entry guard clayman
(DA885246AA68E85698EA6A2585778942090C5AE9) is
unlisted: marking as unusable.
Nov 19 20:45:03.730 [info]
entry_guards_compute_status(): Summary: Entry
'clayman' is reachable, unusable and not live.
Nov 19 20:45:03.730 [info] entry_guard_set_status():
Entry guard h760662
(554EC782556A47590FB5B4DEFF56A5B52DB9CD59) is
unlisted: marking as unusable.
Nov 19 20:45:03.730 [info]
entry_guards_compute_status(): Summary: Entry
'h760662' is reachable, unusable and not live.
Nov 19 20:45:03.730 [info]
entry_guards_compute_status():     (0/3 entry guards
are usable/new)
Nov 19 20:45:03.730 [info] log_entry_guards(): mehl
(down made-contact),clayman (down
made-contact),h760662 (down made-contact)

All of the mentioned guards were actually listed, and
tor had made contact to them on the previous run. 

I tracked it back to revision 12038 where
routers_update_all_from_networkstatus() is called from
router_reload_consensus_networkstatus(). I don't know
what the function does, but commenting it out fixes
the problem and tor stops adding new guards at every
startup. 

There is probably a better fix than that, though. 

Here's a patch against 0.2.0.12-alpha with the above
change. 



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.patch
Type: application/octet-stream
Size: 436 bytes
Desc: 405555701-test2.patch
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20071119/b36923fc/attachment.obj>