[proposal 136] Re: Proposal: Simplify Configuration of Private Tor Networks
karsten.loesing at gmx.net
Thu May 15 19:24:05 UTC 2008
-----BEGIN PGP SIGNED MESSAGE-----
thanks for your comments! Let me see if I can answer them:
|> As first safeguards, Tor should only accept configuration values for
|> V3AuthInitialVotingInterval that divide evenly into the default
|> 30 minutes. The effect is that even if people misconfigured their
|> directory authorities, they would meet at the default values at the
|> latest. The second safeguard is to allow configuration only when the
|> umbrella configuration option PrivateTorNetwork is set.
| Is PrivateTorNetwork for directory authorities only? If so, it should
| be prefixed with V3Auth*. In fact, maybe all options that can only be
| adjusted in a private network should share.
Hmm, no, you need to set PrivateTorNetwork (or however it's called) on
all nodes that are part of your private testing network. Only some
config options are directory-specific, others aren't.
| Also, do we mean "Private" or "Testing"? (This is a bikeshed, I know.)
TestingTorNetwork is okay for me.
| Also, as a safeguard for the system as a whole, perhaps it should be
| an error to specify PrivateTorNetwork without configuring a
| non-default set of dirservers. [ISTR we once did something a little
| like this. Arma: did it end well? :) ]
Ha, good idea! I'll add that.
|> There should be another configuration option DirAssumeRunningDelay with
|> a default value of 30 minutes that can be changed when running private
|> Tor networks, e.g. to 0 minutes. The configuration value would simply
|> replace the quoted constant. Again, changing this option could be
|> safeguarded by requiring the umbrella configuration option
|> PrivateTorNetwork to be set.
| 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?
| If the option is going to do all this, it should definitely be called
| 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 */
| Another interesting issue is: what happens when a controller is used
| to change TestingTorNetwork to 0, or when to reset (say)
| DirAllowPrivateAddresses to its default.
When a controller changes some of Tor's configuration values they are
re-checked just as if Tor had loaded a new configuration, right? In that
case the same rules apply as above, i.e. it's illegal to change
TestingTorNetwork back to 0 but leave depending configuration values
unchanged. This might require some testing to get it right, but the
behavior should (hopefully) be straightforward.
I'll update the proposal and create a new patch these days (probably
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the tor-dev