[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #28849 [Core Tor/Tor]: Handle dormant mode in process library and for PT's
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs