Re: [proposal 136] Re: Proposal: Simplify Configuration of Private Tor Networks

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Thu, May 15, 2008 at 09:24:05PM +0200, Karsten Loesing wrote:
  [...]
> | Sounds good, but DirTimeToLearnReachability would probably be a better
> | name.  I don't think that it needs to be conditioned on
> | PrivateTorNetwork, though: the affect of an authority setting it badly
> | is not "voting fails" but "the authority gets confused and outvoted."
> 
> Sure, I can change the name. But is it useful to change this value on a
> directory authority in the public network?

Hm. I think what we really want to do is instrument an authority to
figure out how long it *really* takes to converge on a view of
routers' statuses; the 30 minute figure was never more than an
estimate that happened to work okay: it may be that a longer or
shorter window would be more reasonable.

But yeah, point taken.  No reason to expose this for non-testing cases.

> | Also, you should define the semantics for
> | specifying TestingTorNetwork *and* a specifying a value for one of
> | these options, as in:
> |    TestingTorNetwork 1
> |    DirAllowPrivateAddresses 0
> | I think that the more specific option should take precedence.
> 
> Right. The implementation might require some code magic as I mentioned
> in the patch:
> 
> /* TODO It should be possible to override those values that are set by
> ~ * "PrivateTorNetwork 1" with the original default values (or even some
> ~ * other value). Idea: Change default values of these configuration
> ~ * options to invalid value, e.g. -1, in order to distinguish default
> ~ * values (then -1) from overridden values, e.g. 0. Requires to safely
> ~ * change all -1 values back to the actual default values afterwards! Is
> ~ * this a hack? Well, of course it is, but is there a better way to
> ~ * achieve the same goal? -KL */

It's kind of an ugly hack too.

What about having a preprocessing step on the options list that
expands PrivateTorNetwork 1 into the entire list of options it
implies? It's not an error to specify an option twice; when you do,
the second takes precedence.

This would mean that RESETCONF wouldn't do the right thing, though.
Perhaps a hack like the one in weasel's debian-tor user patch would
handle that better.  It's still a hack, but not a totally insane hack.
More elegant (maybe) would be a more generic default mechanism that
supported stuff like this by design.

yrs,
-- 
Nick