[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 08:02, David Goulet <dgoulet@xxxxxxxxx> wrote:
>
> On 06 Dec (07:53:16), teor wrote:
>>
>>> 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.
>
> You need a consensus anyway to pick your intro point or HSDir but yes the
> engineering part here will be that if you ever configured v2 service and you
> realize it's v3, we'll rollback all the things.
>
> I agree with you that it could be confusing and will require some fun
> engineering but I think the advantages of having such a thing outweight the
> engineering effort. Unfun part will be on the user side as they will think
> their service is ready to start but then will have a warning after consensus
> download that it's not.
>
> It also means we need to do key creation _after_ consensus download so we
> don't expose the wrong address to the user.
>
> Fun... Maybe we can do better, not sure :S
I'd much prefer a #define for the default, and we can change it in the
next release.
That way, we ensure the code gets proper testing in an alpha series.
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