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

[Matthew Finkel]

On Sat, Nov 26, 2016 at 09:25:44PM +1100, teor wrote:
> 
> > On 26 Nov. 2016, at 02:25, David Goulet <dgoulet at ev0ke.net> wrote:
> > 
> >>> 
> >>> 2) It also means we create an option that will get deprecated once v2 is
> >>>  phased out so we are adding a "temporary" option for users to "keep
> >>>  creating v2 addresses" but then will be useless and we'll deprecate and get
> >>>  a whole lot confusing if for instance v4 or v5 happens in the next years
> >>>  for X reasons (unlikely but not impossible).
> >> 
> >> Not if we use the existing HiddenServiceVersion option for this.
> >> 
> >> Here are the use cases for this option:
> >> * a developer wants to test that their software works with V3 onion services,
> >>  before the default is changed,
> >> * a user wants to run their old software with V2 onion services, after the
> >>  default is changed.
> > 
> > Running v2 onion is fine, it's creating v2 onion that I don't want the user to
> > control when that tor supports v3.
> 
> But what if I have a tor client that only supports v2 onion services,
> (because it has not been updated yet, or is not maintained,)
> and I want to use it with a version of tor that only supports v3
> onion services? (because it has other security fixes I want)

I have a little voice whispering in my head saying "this is a bad idea!".

Similarly, "This is not supported" is the ideal solution for this scenario,
but being the realist that I am, *someone* will try this and it should work
for them. Specifically, I'm thinking about the Jessie and Wheezy users who
are using a system tor (as was mentioned earlier). I'm torn because they are
doing it wrong, but at the same time, is it their fault? The various other
distros are another nightmare. Luckily most users should be using Tor
Browser/Messenger, but that doesn't help the edge cases.

I agree HiddenServiceVersion is useful for providing this transition, but I'm
worried this option maybe more surprising than intended, and the manpage's
description would need some changes. Currently, the implementation is only
asserts the v2 is set (since 2009), so luckily backwards compatibility is not
actually a concern. However, the description says:

   A list of rendezvous service descriptor versions to publish for the hidden
   service.

This isn't what we'd want. This is actually the wrong side of tor from what is
being discussed. The purpose of this option would change from the descriptor
publication side to being something user-facing. Although this option is not
currently useful, I worry about repurposing it for specifying how an onion
service should be created. Yes, the onion-service-version and the version of
the descriptor that tor publishes are now tightly coupled, comparing v2 and v3.
However, this may not always be the case and, indeed, was not the case
previously. I'm not saying HiddenServiceVersion is not the correct torrc
option, but please keep these problems in mind. Also, realize that the current
torrc syntax allows multiple versions (so it would allow tor create both a v2
and v3 descriptor, and if this is used for onion service creation, it could
create both v2 and v3 rend services).

> 
> I would prefer we release at least one version with v3 as the default,
> but that will still create v2 if asked nicely.
> 
> (Alternately, we can tell people how to create v2 manually, or we can
> tell people to keep their old version of tor and make it create v2.)

Ugh. None of these are good, but releasing a tor version with v3 creation as
the default and hiding v2 creation behind a torrc option seems like the best
and least astonishing decision. I fully agree with David that this is not ideal
and v2 should die sooner than possible. However, I'm not convinced this is
realistically the best move.

Luckily this isn't my decision, so take my 2 cents however you want.</bikeshed>

- Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161127/fd050c4d/attachment.sig>