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

teor teor2345 at gmail.com
Wed Nov 23 23:25:38 UTC 2016

> On 24 Nov. 2016, at 09:00, Yawning Angel <yawning at schwanenlied.me> wrote:
> On Wed, 23 Nov 2016 03:12:22 +0400
> meejah <meejah at meejah.ca> wrote:
>> David Goulet <dgoulet at ev0ke.net> writes:
>>> 1) Once v3 is released, from that point on _no_ v2 service will be
>>> allowed to be created by "tor" itself. It will always be possible
>>> to do it by hand by creating an RSA key and putting it in the
>>> service directory (see 3 below).  
>> +1 or +2 at least :)
>>> Ok here it is. Please comment, improve, or propose! :)  
>> How does ADD_ONION fit in?
> It's forward compatible by design, since you have to specify a key type
> when you handle key management, and Tor gets to do whatever it wants if
> you ask it to generate a key with the `BEST` algorithm.
> Assuming people who use it aren't explicitly asking for RSA1024, their
> apps will magically switch to using Ed25519 automagically one day, when
> their tor is updated.
> (People who expect `NEW:BEST` ADD_ONION-ed services to always give
> RSA1024 based HSes, should fix their code since the spec makes no
> guarantee that `BEST` will be RSA1024.)


(I've changed my opinion, adding a new command is pointless.
People who want the old ADD_ONION behaviour where BEST produces a v2 HS
can use an older version of Tor, until the software that makes
incorrect assumptions is updated.)


Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
xmpp: teor at torproject dot org

More information about the tor-dev mailing list