tor/changes/bug6507
Nick Mathewson dfe03d36c8 Don't infer we have a FooPort from the presence of a FooPort line
Thanks to the changes we started making with SocksPort and friends
in 0.2.3.3-alpha, any of our code that did "if (options->Sockport)"
became wrong, since "SocksPort 0" would make that test true whereas
using the default SocksPort value would make it false.  (We didn't
actually do "if (options->SockPort)" but we did have tests for
TransPort.  When we moved DirPort, ORPort, and ControlPort over to
the same system in 0.2.3.9-alpha, the problem got worse, since our
code is littered with checks for DirPort and ORPort as booleans.

This code renames the current linelist-based FooPort options to
FooPort_lines, and adds new FooPort_set options which get set at
parse-and-validate time on the or_options_t.  FooPort_set is true
iff we will actually try to open a listener of the given type. (I
renamed the FooPort options rather than leave them alone so that
every previous user of a FooPort would need to get inspected, and so
that any new code that forgetfully uses FooPort will need fail to
compile.)

Fix for bug 6507.
2012-08-09 15:48:43 -04:00

8 lines
428 B
Plaintext

o Major bugfixes:
- Detect 'ORPort 0' as meaning, uniformly, that we're not running
as a server. Previously, some of our code would treat the
presence of any ORPort line as meaning that we should act like a
server, even though our new listener code would correctly not
open any ORPorts for ORPort 0. Similar bugs in other Port
options are also fixed. Fixes bug 6507; bugfix on 0.2.3.3-alpha.