tor/changes/bug6507

  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.
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 21:48:43 +02:00			`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.`