[tor-dev] [RFC] control-spec: Specify add/remove/view client auth commands (client-side).

[David Goulet]

On 06 May (18:19:58), George Kadianakis wrote:
> Hello list,
> 
> here is a control spec patch for adding v3 client auth commands to
> add/remove/view clients from the client-side (so Tor Browser -> Tor):
>                 https://github.com/torproject/torspec/pull/81/commits/3a26880e80617210b4729f96664ef9f0345b0b7c
> 
> I'm currently unhappy with the naming of those commands, and in general
> with how easy it is to confuse them with the (non-existent) service-side
> commands. I'm wondering how to name them better so that when we add the
> respective service-side commands (at some point we should) there is no
> confusion.

Very nice!

(Replying here so tor-dev@ sees it all and do not miss comments on the PR.)

1. So yes on the naming and a way to highlight service vs client. The command
   naming scheme on the control port is a bit chaotic and I'm all for one
   trying to come up with "namespace" a bit better.

    HSPOST, HSFETCH, ADD_ONION, DEL_ONION...

    We can't change the above but we can at least from now on try to come up
    with a better naming related to onion services.

    Something like:

        - ONION_CLIENT_ADD_AUTH
        - ONION_CLIENT_DEL_AUTH
        - ONION_CLIENT_LIST_AUTH

    I know a bit long but these commands in the end should rarely be typed by
    a human person anyway.

    And if we have service side only commands, we use:

        - ONION_SERVICE_...

    Not sure we'll ever have a command that applies to both a service and a
    client... maybe who knows, but then we can either do two commands or just
    generalized on:

        - ONION_ ...

2. We need LIST/ADD/DEL to specifies what code is returned in case of success
   and error. There can be many errors like "Key blob unparseable" or
   "HSAddress" is invalid or "a client auth already exists" which I assume for
   this we will force the user to remove/add instead of replacing.

3. The VIEW_ONION_CLIENT_AUTH, for "Type", I think you need to define this
   differenlty:

    [SP "Type=" TYPE]

    and then define TYPE:

    TYPE can be:
        "Permanent" - <description>...

Cheers!
David

-- 
nUXe6UT7bN7R6NGT2ZAAfdBXWLxXg2jRjmun1U49Zcs=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190506/287ed782/attachment.sig>