[tor-dev] prop224: What should we do with torrc options?

[George Kadianakis]

David Goulet <dgoulet at ev0ke.net> writes:

> On 06 Dec (10:09:57), teor wrote:
>> 
>> > On 6 Dec. 2016, at 09:56, David Goulet <dgoulet at ev0ke.net> wrote:
>> > 
>> > <snip>
>> >
>> 
>> Here's a suggested strategy:
>> * at load time, validate the HS options as if v2 is the default, and
>>   validate them as if v3 is the default, and fail if either validation
>>   fails.
>> * then, act on the HS options as if v2 is the default, and also act as
>>   if v3 is the default, and fail if either action fails.
>>   (We need to do this because we don't discover some option issues
>>   until runtime, such as whether the directory can be created.)
>> * then, when each consensus is downloaded, publish whichever descriptor
>>   is the default in the consensus (if the HS config does not specify
>>   a specific version).
>
> This is a reasonable way to proceed considering we use a consensus param to
> know which version of default HS to create. I see this as more of an
> engineering problem that can be solved.
>
> Which what I would like us to decide on if we think that consensus param
> controlling the default version is a good idea or not. If we think yes, we can
> pull it off, if not everything is simpler :).
>
> So just to be clear, I'm behind you on the concern of making sure we validate
> the options on launch instead of failing at consensus download. There are ways
> we can address that like you outlined above.
>

Hello,

I agree that this is more of an engineering problem that can be
solved. I also like the agility that the consensus parameter gives us.

That said when we get close to implementing this feature, IMO we should
estimate how long it will take us to implement this consensus parameter
logic, and evaluate whether it's worth doing. This feature might be an
evening of work, but it could also be two annoying weeks of testing and
debugging crazy networking and consensus fetching edge cases, so we
should make sure we don't sign up for too much craziness.

The alternative would be that we don't do the consensus parameter, and
instead we just change the version parameter in alpha/stable releases
when we feel it's ready. This will be a slower and more gradual
deployment which is not necessarily a terrible thing when we are talking
about huge features like prop224.