[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: unspecified
Component:  Core Tor/Tor  |        Version:  Tor: unspecified
 Severity:  Normal        |     Resolution:
 Keywords:  041-proposed  |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:  Sponsor19
--------------------------+----------------------------------

Comment (by dcf):

 Replying to [comment:7 ahf]:
 > I've tried to make a proposal patch here:
 https://github.com/ahf/torspec/commit/49d1cf355c350816ded4ea2e7d5772042aaa9d08

 This looks pretty good.

 * "The PT proxy SHOULD respond to the `FEATURES` message using the
 `FEATURES-ACK` message..."
   * Does the PT proxy necessarily have to wait for `FEATURES` before
 responding with `FEATURES-ACK`? It would be simpler if both sides just
 send a `FEATURES` line declaring their own features.
 * "...a comma-separated list of ''mutually supported'' features..."
   * Maybe the "mutually supported" isn't necessary. It's simpler if both
 sides just declare ''all'' the features they support. Otherwise you also
 have to specify what should happen if a PT proxy violates the spec and
 declares a feature set that is not a subset of the parent process's
 feature set--which is probably that the parent process should ignore the
 features it doesn't support, which amounts to the same.
 * "The PT proxy SHOULD respond to the `FEATURES` message..."
   * I think this needs some language saying what it means if the PT proxy
 does not respond to the `FEATURES` message (backward compatibility); i.e.,
 that the PT proxy's feature set is the empty set. Symmetrically for the PT
 proxy's interpretation: lack of a `FEATURES` option means the parent
 process's feature set is the empty set.
 * "Example message from parent process to PT proxy: `FEATURES
 dormant,x,y`"\\
   "Example response from PT proxy to parent proxy: `FEATURES-ACK
 dormant,y`"
   * I would like the spec to say what should happen when the feature set
 is empty. Specifically, whether a space character is required before the
 null list, `FEATURES` or `FEATURES `.
 * "...the `FEATURES` message that is written to the PT proxy's standard
 input."
   * Why is `FEATURES` on standard input, and not an environment variable
 like every other global configuration? There's no grammar yet in the spec
 for parent→PT standard input messages (presumably it looks like section
 3.3). If `FEATURES` is on standard input, what happens if it is sent more
 than once? What happens if it is sent more than once with different
 feature sets?
 * "Once the Pluggable Transport Specification version have been
 successfully negotiated..."
   * The spec should say when the PT proxy is allowed to send `FEATURES-
 ACK` is allowed and when it is not allowed. It has to be after `VERSION`.
 Can it come after `CMETHODS DONE` or `SMETHODS DONE`? What happens if the
 PT proxy sends it more than once?
 * "The PT proxy MUST acknowledge the request using: `SIGNAL DORMANT-ENTER-
 DONE`"
   * What happens if the parent process sends `SIGNAL DORMANT-ENTER` more
 than once without an intervening `SIGNAL DORMANT-EXIT`? Must the PT proxy
 acknowledge each one, even when it has not changed its own state? I.e.,
 are the acknowledgements edge-triggered or level-triggered?
   * Personally I would remove the MUST language here as it's kind of
 ineffectual--can a PT proxy reply with `SIGNAL DORMANT-ENTER-DONE` 60
 seconds later? Is the parent process going to wait and enforce the MUST?
 If not, it's not really a MUST. I feel the MUST language will encourage PT
 proxies to lie about their current state (I need to send `SIGNAL DORMANT-
 ENTER-DONE` because the spec says so, even if I currently am not capable
 of going dormant). What tor is really interested is not whether the PT
 proxy has received and understood the `SIGNAL DORMANT-ENTER` message, it's
 the points in time when the PT proxy actually changes its dormant state,
 so the spec should reflect that.
   * I would make the messages the same in both directions; e.g. use
 `SIGNAL DORMANT-ENTER` in both directions, without a special `SIGNAL
 DORMANT-ENTER-DONE` in the PT→parent direction.
     * Or even simplify more: `DORMANT ENTER` and `DORMANT EXIT`.

 Side note, one of the features I would like tor to advertise is `reads-
 stdout`, so a PT proxy can know whether it's safe to use `LOG` or not.

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