[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #28692 [Core Tor/sbws]: sbws should set ConnectionPadding 0

#28692: sbws should set ConnectionPadding 0
---------------------------+-----------------------------------
 Reporter:  teor           |          Owner:  (none)
     Type:  defect         |         Status:  needs_revision
 Priority:  Medium         |      Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:                 |  Actual Points:
Parent ID:                 |         Points:
 Reviewer:  teor           |        Sponsor:
---------------------------+-----------------------------------

Comment (by teor):

 Replying to [comment:6 juga]:
 > Replying to [comment:4 teor]:
 > [...]
 > > Here's a simpler design:
 > > * a list of torrc options in stem.py,
 >
 > Even if only stem.py uses these options, i think they should be in
 globals.py, since we might need to change them and globals.py should be
 the place where to change sbws defaults.

 Let's leave any refactoring until #28737.

 > > containing 1., 2. and 4., with a flag saying when the option should be
 applied to tor (1. and 2. on launch, 4. after launch)
 > > * a custom list of torrc options that the user can configure for
 launch (same as 3.)
 > >
 > > (There's an even simpler design in #28712 that makes 3. into a torrc
 file, but it's a breaking change.)
 >
 > There isn't a stem torrc syntax parser. This code
 (https://github.com/torproject/sbws/blob/master/sbws/util/stem.py#L157)
 was implementing part of it, it's not complete but was working with well-
 formatted torrc lines.
 > I found that the parser for stem configuration
 (https://stem.torproject.org/api/util/conf.html) is very close to what a
 torrc parser would need, yet might not support all the cases
 (https://github.com/torproject/tor/blob/master/doc/torrc_format.txt).

 Why write a parser, when tor will parse lines for us?

 > Options:
 > 1. we use stem.util.conf, let tor launch fail when options can't be
 parsed and inform the operator
 > 2. we extend stem.util.conf to become a torrc parser
 > 3. we implement a full torrc parser
 > 4. we accept torrc options only in the form of an INI file, which would
 be parsed by ConfigParser and converted to the stem's torrc dictionary
 (i'm not sure which cases might fail here either)

 Option 4 is #28737, and it should work reasonably well. But it's a new
 feature, so it belongs in sbws 1.1.

 Here's another option:

 5. Fix sbws' current tor option parsing code:
   * allow options with no argument (#28715)
   * stop trying to merge sbws options with the same name (#28738), until
 we refactor in sbws 1.1 (#28737)
 Then tell the operator if tor doesn't like the options.

 Now the option bugs are dealt with in other tickets, let's talk about this
 ticket.

 Here's a simple algorithm for ignoring failing options:
 1. sbws has OPTIONS, a hard-coded list of options and values, and
 CAN_FAIL, a hard-coded, ordered list of options that are allowed to fail
 2. Try launching tor with OPTIONS
 3. If tor fails to launch:
   * if CAN_FAIL is not empty, remove the first option in CAN_FAIL from
 OPTIONS, and go to step 2
   * otherwise, edit sbws with an error
 4. Log a message with the Tor version, and the CAN_FAIL options that were
 removed from OPTIONS

 Let's put this new code in a new function. launch_tor is already almost
 100 lines long.

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