[tor-bugs] #6411 [Tor]: Adding hidden services through control socket

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Mar 19 15:48:43 UTC 2015


#6411: Adding hidden services through control socket
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  yawning
  kevinevans             |     Status:  needs_revision
         Type:           |  Milestone:  Tor: 0.2.7.x-final
  enhancement            |    Version:  Tor: 0.2.3.19-rc
     Priority:  normal   |   Keywords:  hidden-service control maybe-
    Component:  Tor      |  proposal tor-hs globalleaks-wants
   Resolution:           |  Parent ID:  #8993
Actual Points:           |
       Points:           |
-------------------------+-------------------------------------------------
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 Here is what I have after a first review. Very awesome feature I might add
 :).

 1) `crypto_pk_base64_decode()`

     * `size_t der_len` should be checked against <= 0 because
 base64_decode()
     can return negative value.

 2) `handle_control_add_onion()` --> HUGE :)

     * `tor_parse_long(port_str, 10, 1, 65536, NULL, ...`, shouldn be 65535
 here
     else 65536 is accepted and currently abort if used.

     * I think TARGET needs to be validated because this makes tor die
 (crazy
     IP):

     {{{ADD_ONION NEW:BEST Port=65535,181.121.123.1116:655}}}

     Quite related to previous port bug. Didn't investiguate more but seems
 `service->ports` is invalid in some way.

     * `if (!strcasecmp("RSA1024", key_type)) {`, I would continue the good
     practice of using "static const char *" like you did with `Flags=` and
     `Port=`. Same for `BEST` and `NEW`.

 3) `handle_control_del_onion()`

     * `if (onion_services == NULL || idx == -1) {`, the "idx == -1"
 doesn't seem useful.

     * In this function, the given service ID is not validated so it's
 blindly
       passed to `rend_service_del_ephemeral` which validates it and can
 return
       an error. The comment `This should *NEVER* fail,` is wrong in that
 sense.
       I think would be good if you could inform the user that the service
 ID is
       malformed in the first place instead of a generic "Failed to remove
 Onion
       Service" error?

 4) `rend_config_services`

     * This comment is a bit confusing. Can you clarify why you are doing
 that?
     {{{
     /* Pull all the ephemeral services out of old_service_list and add
 them
      * into rend_service_list so they remain active and
 surviving_service_list
      * so the intro points don't get closed.
      */
     }}}

 5) `rend_service_add_ephemeral`

     * Documenting the returned value would be desirable. (same for
 del_ephemeral)

     * `s->directory = NULL; /* This indicates the service is ephemeral. *`
 I
       would also document that in the structure definition in
 rendservice.c at
       the top.

     * This function has some code duplication from
 `rend_config_services()`. I
       would advocate for a kind of "rend_service_create" function that
 would do
       the allocation and initialization. We can even split that into
 "create()"
       and "init()" if you prefer. You even add this comment in
 del_ephemeral() ;)
       for which I agree and should be done.
       {{{
        * XXX: As with the comment in rend_config_services(), a nice
 abstraction
        * would be ideal here, but for now just duplicate the code.
       }}}

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6411#comment:45>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list