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

[David Goulet]

On 20 Dec (17:44:31), George Kadianakis wrote:
> 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.

Agree. In a matter of few hours, we'll know if this is too much engineering
with lots of corner case untested or actually doable easily.

The fallback to use the parameter is a good idea to avoid going overboard if
we realize it is kind of crazy.

Cheers!
David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161220/00b947f9/attachment.sig>