[tor-bugs] #9199 [BridgeDB]: Rethink the logging of BridgeDB

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Jul 4 11:01:23 UTC 2013

#9199: Rethink the logging of BridgeDB
 Reporter:  asn       |          Owner:                   
     Type:  task      |         Status:  needs_information
 Priority:  normal    |      Milestone:                   
Component:  BridgeDB  |        Version:                   
 Keywords:            |         Parent:                   
   Points:            |   Actualpoints:                   

Comment(by asn):

 Replying to [comment:2 sysrqb]:
 > Nearly finished with an initial branch. some thoughts/questions:
 > a) Should we scrub the bridge's fingerprint when safe logging is not
 disabled? It can easily be used to retrieve the IP addr via Atlas, etc.
 Maybe we should hash the fingerprint by default so various aspects of the
 log file are linkable?

 Hm, do we even care about scrubbing the IP addresses of bridges? I was
 mostly worrying about clients IPs.

 > b) Using the extended nickname will probably not be in v1 of this patch.
 It will be a little invasive to retrieve/store all the info we need.

 Sure. No problem.

 > c) I think providing a heartbeat is a nice idea. How do you feel about
 displaying uptime, user GEOIP stats, OS stats (based on user-agent) over
 the past n hours? This won't be trivial, but it shouldn't be too
 difficult. I think we should push this to v2 also.

 Yeah, I also like heartbeats.

 BTW, be aware that if you want a "X unique IPs asked for bridges during
 the last N hours" dialog, you also need to keep client IPs in memory. We
 should probably not do that.

 > d) If we're auditing the logging, do we want to consider switching to
 twisted.python.log]? Isis brought this up a few weeks ago. If we're going
 to make a decision on it, now is a fine
 time.[https://twistedmatrix.com/trac/wiki/TwistedLogging 0]

 Hm. How hard would it be to switch to twisted.logging?  What are the
 advantages of using Twisted logging? Do we care about them?  If the
 advantages are not too great, I'd rate this as low-priority and probably
 do something more important if it takes more than 2 hours of

 It's up to you :)

 > I'm prioritizing some features/enhancements (mainly adding more debug
 output and scrubbing) due to the importance of solving #9174. The faster
 we are able to fix that, the better.

 Sounds good.

Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9199#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

More information about the tor-bugs mailing list