[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] prop224: What should we do with torrc options?
> On 6 Dec. 2016, at 07:42, David Goulet <dgoulet@xxxxxxxxx> wrote:
>
> On 22 Nov (17:36:33), David Goulet wrote:
>> Hi everyone!
>>
>> We are soon at the stage of implementing the service part of proposal 224
>> (next gen. hidden service.). Parent ticket is #20657 but I'll be discussing
>> here ticket #18054.
>>
>> In a nutshell, we need to figure out the interface for the torrc file[1]. We
>> currently have some options to configure an hidden service and the question is
>> now how do we proceed on using those for next version?
>
> [snip]
>
> (Please read original email for some initial context.)
>
> So over the last week, we've mashed up all the things that were said in this
> thread, me and asn discussed it with some arma also on the side!
>
> I think the following is the best of all the non ideal solutions we can come
> up with. Below is a superb ascii timeline of what we plan to do in terms of
> transition from v2 to v3:
>
>
> Our dystopian reality of now.
> (https://youtu.be/NrmMk1Myrxc
> it's not a Black Mirror SO3 trailer)
> v
> | ~Aug '17 ~Dec '17 Unknown date
> |-----------------|-----------------|----------------|---------->
> | ^ ^
> ^ v3 Network/Code |
> tor stable release Maturity |
> with v3 support No more v2
> (0.3.1)
>
> Ok, might not be my best ascii art work but I hope it will do. In short:
>
> - With 0.3.1 (scheduled for August 2017, subject to change), we'll have a tor
> with v3 support BUT v2 will still be the default value for *new* HS.
> (HiddenServiceVersion option)
>
> - For a period of ~4 months we estimate, we'll hope that enough of the network
> has upgraded to support v3 (relay and HSDir support are in 030) and that the
> code as some sort of maturity that we are confident to switch and make all
> new HS be v3. This is the "v3 Network/Code Maturity" marker. Note that it
> could easily go to 2018 for this switch to happen.
>
> - When the switch happens, there will be, most likely years, a long period of
> time where v2 will be deprecated and warnings given to users but still used.
> That "Unknown date" will be the time we will release a tor stable version
> _without_ v2 support at all. It's quite unknown when we'll be able to do it.
> Chances are that we'll rely on our HS statistics and metrics for that.
>
> That being said, here are the conclusions based on this thread and f2f
> discussion considering the above "procedure":
>
> 1) When v3 is released in a tor stable version, it will NOT be the default
> version for new service, v2 will until maturity.
>
> 2) HiddenServiceVersion is used to control which version of the service you
> want. Starting from the first time v3 is supported, you'll be able to use
> it but without any guarantee as we'll be entering the "stabilizing period"
> but it should be usable.
>
> 3) ADD_ONION "BEST" will map to whatever default value HiddenServiceVersion is
> with the tor you have.
>
> 4) In order to avoid relying on a tor stable version release to switch the
> default version from 2 to 3, we'll use a consensus parameter. Meaning that
> once we set that param. to v3, HiddenServiceVersion default value will be
> that value unless explicitely defined in torrc. It will also allow us to
> rollback to v2 if we see a swarm of badness occuring. To be clear, service
> already v3 will stay v3 but the default version for creation will simply
> change.
> ...
This is problematic: we validate and create onion services at torrc
load, before loading the consensus.
Do we plan to do it afterwards?
That seems like it could be really confusing.
T
--
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev