> On 21 Feb 2019, at 00:29, Nick Mathewson <ni...@alum.mit.edu> wrote: > > On Mon, Feb 11, 2019 at 7:00 AM teor <t...@riseup.net> wrote: >> >> Hi all, >> >> I have a Tor proposal idea: we should make it easier for tor to get options >> from the consensus. >> >> At the moment, a few tor options are set from the consensus. (If they aren't >> already set in the torrc.) But there's no abstraction in tor's code, so >> they're all implemented slightly differently. >> >> We could refactor the code so these options are much easier to declare. And >> we could provide a graceful upgrade path from off-by-default features, to >> on-by-default features. > > This is a cool idea, and something to think about as we refactor the > configuration handling code. > > One area I'd want a proposal like this to consider is what we'd be > expecting other implementations of the Tor protocol to do. If we put > an option-setting-feature into the consensus like this, does that > option's behavior in Tor become part of the spec? I think the > simplest answer here is "yes, the option must be documented as part of > the spec". > > >> 1. Tor refactoring >> >> We refactor the tor config code, so that options can be declared as >> consensus options. If the option is configured locally, that value is used. >> Otherwise, the consensus value is used. If there is no configured or >> consensus value, the default is used. >> >> Each entry in the option declaration table would need 3 extra values: >> * a flag that tells tor whether to check the consensus >> * a minimum permitted value from the consensus >> * a maximum permitted value from the consensus >> >> At the same time, we might also want to: >> * declare a minimum and maximum value for all options, not just the >> consensus options >> * add a log message fragment that explains the value restriction > > I'd also suggest that we also have an entry that tells us which > consensus parameter to look at, so that the consensus name doesn't > need to be the same as the option's name. We'd need this for backward > compatibility at any rate.
I agree: I thought of this after I sent the email. (And then I forgot, because I was on leave.) >> So far, this is a refactoring idea. But here's where it gets interesting… >> >> 2. Tor authority behaviour change >> >> We also want to gracefully upgrade new features, so that they are >> on-by-default. >> >> For privacy sensitive features, we would keep the current process: >> 1. Deploy the feature off-by-default, but make it a consensus option >> 2. Manually change the consensus parameter so the option is on-by-default >> 3. Change the next release of Tor so the option is on-by-default >> 4. When all supported Tor versions have the feature on-by-default, manually >> remove the consensus parameter >> >> This upgrade path allows us to make sure that almost all the network has the >> same behaviour. >> >> But for other features, we could upgrade faster: >> 1. Deploy the feature off-by-default, but make it a consensus option >> 2. Change the next release of Tor so the option is on-by-default >> 3. When the authorities upgrade to the next release, they automatically vote >> the consensus parameter on-by-default >> 4. When all supported Tor versions have the feature on-by-default, remove >> the flag telling authorities to write the consensus parameter from the option >> 5. When the authorities upgrade to the next release, they automatically stop >> voting for the consensus parameter >> >> This upgrade path turns the option on when a majority of authorities >> upgrade. We wouldn't be able to use it for options where flapping is an >> issue. > > Relatedly (?), one case that we sometimes have wanted in the past is > the ability to disable an option or enable it for only a range set of > versions. For example, we'd implement an off-by-default feature as a > consensus option ... and then discover some bug in the implementation > of that feature before we turned it on. It seems like implementing versions in the consensus could get really complicated. Here's one way to deal with that scenario: * When the fix is implemented, rename the consensus parameter (but keep the same torrc option name) * Keep the old consensus parameter off, but set the new consensus parameter once we're sure the bug is fixed For example: Let's say that release 1.1.0 has a MakeTorFaster option, with a MakeTorFaster consensus parameter. It's off by default, so the authorities set MakeTorFaster=0. But in release 1.3.0, we discover that 1.1.0 and 1.2.0 had a broken MakeTorFaster implementation. So we fix MakeTorFaster in 1.3.0, and call the fix MakeTorFaster_130 in the consensus. The authorities start by setting MakeTorFaster=0 and MakeTorFaster_130=0. Then, when we're happy with the fix, we set MakeTorFaster_130=1. (But leave the broken option off.) Then, 1.3.0 and later are configured with MakeTorFaster, but the broken versions are not. T
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
