#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@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
