Re: [tor-bugs] #28181 [Core Tor/Tor]: spec: Add to pt-spec.txt control messages going back to main process (tor)

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

#28181: spec: Add to pt-spec.txt control messages going back to main process (tor)
-------------------------------------------------+-------------------------
 Reporter:  dgoulet                              |          Owner:  dgoulet
     Type:  enhancement                          |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.6.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-spec, tor-pt, 036-roadmap-       |  Actual Points:
  subtask                                        |
Parent ID:  #28180                               |         Points:
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor8
-------------------------------------------------+-------------------------

Comment (by dcf):

 Replying to [comment:7 dgoulet]:
 > Thanks dcf1! Lets again turn this around, what do you think about:
 >
 > {{{
 > LOG <level> <msg>
 > }}}
 >
 > The idea is for a PT (optional) to be able to report back logging
 messages to the main process. In the case of Tor/TB, we would use those,
 write them to our logs at the <level> and send them to the control port.

 Yes! `LOG` is exactly what I've wanted for pluggable transports for a long
 time. IMO it's the !#1 missing feature. I was disappointed when PT 2.0 had
 nothing to say on the subject, and kind of quit hoping after that.

 A loglevel is a bit of a tor-ism, so you should check with non-tor PT
 implementers to see if they are happy with it. obfs4proxy already has a
 `-logLevel` option with values `ERROR`/`WARN`/`INFO`/`DEBUG`, so you may
 want to try enabling those options and looking at the log file, as a
 preview of the kind of messages tor will be receiving.

 `LOG` is great for PT developers; but I fear that's not what this ticket
 was originally about, which is providing some kind of user interaction
 feedback during connection establishment. If I'm correct that tor is
 currently not reporting {SOCKS connection, SOCKS success, SOCKS failure}
 events through the control port, I think that would be a good place to
 start, because all PTs already implement that and it seems equivalent to
 what you proposed in comment:5.

 One thing to keep in mind: PT stdout messages are per-process, not per-
 bridge or per-connection. It may not be the IPC mechanism you're looking
 for, depending on what you need to accomplish. It's common, for example,
 to run one client instance of obfs4proxy with multiple bridges
 simultaneously (with multiple different transports even). If you want log
 messages about the connection status of just one bridge, `LOG` won't do
 that (unless you force the messages to contain the remote IP and port, a
 bad idea IMO). `LOG` is only good for global status messages like "cannot
 open log file" or "panic in subroutine xyz", or for debugging where you
 don't mind inferring connection info manually. For per-connection status
 you're better off using SOCKS events.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28181#comment:8>
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