[tor-bugs] #28849 [Core Tor/Tor]: Handle dormant mode in process library and for PT's

[Tor Bug Tracker & Wiki]

#28849: Handle dormant mode in process library and for PT's
--------------------------+------------------------------------
 Reporter:  ahf           |          Owner:  (none)
     Type:  enhancement   |         Status:  needs_review
 Priority:  High          |      Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |        Version:  Tor: unspecified
 Severity:  Normal        |     Resolution:
 Keywords:  042-proposed  |  Actual Points:
Parent ID:                |         Points:
 Reviewer:  dcf           |        Sponsor:  Sponsor19
--------------------------+------------------------------------

Comment (by dcf):

 Thanks, I think we can work with this design.

 * "If no feature extensions are supported by the parent process this
 variable SHOULD be left empty."\\
   "The PT proxy SHOULD announce its own set of supported feature
 extensions ..., but only if the `TOR_PT_FEATURES` environment variable is
 present."
   * I don't understand the reason for forbidding the PT proxy from sending
 `FEATURES` when `TOR_PT_FEATURES` is not set/present. I think the PT proxy
 should always be free to send `FEATURES`. 3.3 already says "The parent
 process MUST ignore lines received from PT proxies with unknown keywords,"
 so it's safe.
   * There's an ambiguity with the terms "empty" and "present". They could
 mean "the environment variable is unset" or "the environment variable is
 set to an empty string." IMO it's best if both of those possibilities have
 the same meaning.
 * "less resource conserving"
   * Should be "more resource conserving".
 * "The PT proxy MUST only write the `FEATURES` message once during the
 lifetime of the PT proxy process."
   * IMO it's better to specify what should happens if this is violated;
 e.g., the parent process must ignore any `FEATURES` line after the first.

 I can live without it, but because messages from the parent process to the
 PT proxy on stdin are a major change to the spec, it would be good to have
 something analogous to 3.3 (or make 3.3 more general) that says what those
 messages look like, what should happen if there's an unknown message
 (ignore), etc.

 You should invite the author of
 [https://github.com/twisteroidambassador/ptadapter ptadapter] to comment
 on the changes, because they will have to implement the parent process
 half.

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