Re: [tor-bugs] #10059 [Core Tor/Tor]: capture tor log messages before control connection is opened

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#10059: capture tor log messages before control connection is opened
-------------------------------------------------+-------------------------
 Reporter:  mcs                                  |          Owner:  nickm
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  unspecified
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-usability, extdev-interview,     |  Actual Points:
  tor-03-unspecified-201612, tbb-wants           |
Parent ID:  #9675                                |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by arma):

 Replying to [comment:12 mcs]:
 > For Tor Launcher, it would be convenient to have a mechanism in tor such
 as the one you described. One tricky thing is that we would want to be
 sure Tor Launcher receives the entire, correct stream of messages (without
 duplicates or gaps), so we would need to figure out how to merge the
 queued messages with the ones we receive in response to SETEVENTS NOTICE
 WARN ERR. I am not sure how to do that unless tor assigns a sequence
 number or something similar to each message. Or it might work for tor to
 provide an option to send the queued messages as events as soon as the
 SETEVENTS command is received.

 In discussions with catalyst today, I think we hit upon a plausible
 approach: you start Tor with a config setting to enable this behavior, and
 then there's a single atomic controller command that a) pastes out all the
 queued messages to the controller, and b) stops queueing messages.

 So the controller would connect, issue SETEVENTS commands the way it
 wants, possibly getting a few new events, and then it would request the
 old events. It would know that the old events came before the new ones,
 and it would also know that there aren't any duplicates.

 Then Tor could keep on logging, sending events, etc just as it does now,
 but it would keep copies of them for when the controller comes asking.

 Plausible?

 For simplicity, we probably want to hard-code the types of events that get
 queued, rather than having the config option be flexible enough to hear
 which events you wanted. Or we could queue them all, and let the
 controller pick through them, but that could potentially get really big
 really quickly if it includes e.g. debug log events.

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