On Sat, Nov 26, 2016 at 09:25:44PM +1100, teor wrote: > > > On 26 Nov. 2016, at 02:25, David Goulet <dgoulet@xxxxxxxxx> 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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev