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

[Yawning Angel]

On Thu, 24 Nov 2016 01:43:15 +0200
s7r <s7r at sky-ip.org> wrote:
> I agree that this would be "the technical way" to do it, but real
> world usability kind of prevents us to do it this way. The spec for
> ADD_ONION indeed does not say that v2 hidden services will be
> supported forever and it clearly SHOULD NOT, but it also doesn't make
> much sense to abolish it at the first Tor release supporting v3
> services (because if we make ADD_ONION == v3 (best) this is what we
> are doing).

Even I don't think `BEST` should be changed to Ed25519 immediately,
especially when the code is being stabilized.

That is a completely orthogonal to the fact that people that have dumb
limitations like:
> Bitcoin Core - latest versions detect if you use Tor and automatically
> use ADD_ONION to create v2 services, and, important: it doesn't
> support yet the v3 address types because of their length. This way
> people behind NAT running it can be better connected by accepting
> incoming connections without an open port, some people don't want
> their upstream provider to know they are using this app, etc.

Should be using `NEW:RSA1024` explicitly.  The override is there for a
reason, and the key type is part of the serialized data that tor
returns to you when you have it generate a key, precisely to avoid this
sort of problem.

Their fix: "Replace line 473 of bitcoin/torcontrol.cpp with
`private_key = "NEW:RSA1024";`".

Our fix: "Add another command, that does essentially the same thing,
because people picked the wrong options, then later deal with the
fallout from people getting used to the temporary command, and crying
when it's deprecated."

I say "they should fix their code".

> I don't think it's productive to ask users to already support a new
> feature upon our first release providing the said feature.

If they aren't using existing interfaces correctly, when correct
behavior has been part of the interface since support for it was
added, quite frankly it's their problem.

Regards,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161124/5dadded7/attachment.sig>