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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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:           |
-------------------------+-------------------------------------------------

Comment (by yawning):

 Replying to [comment:36 atagar]:
 > Hi yawning, your spec addition looks great! Delightfully precise, I
 like. :P
 >
 > Only thoughts are...
 >
 > * Maybe add the following note to the end of ADD_ONION? "Controllers
 MUST tolerate unrecognized keyword arguments."

 This is for the response right?  Sure, I'll add that, since part of the
 motivation for the "NEW:BEST" method of keypair generation is to allow old
 controller libraries to work with newer tor instances that support new and
 exciting key types (the value of `PrivateKey=` can just be passed back
 into `ADD_ONION` as an opqaue blob at a later date, even if the controller
 can't parse it to recreate a given HS).

 > * You might want to consider making 'DiscardPK' a keyword argument
 instead ('DiscardPK=1'). That's more common for booleans like this than a
 positional argument.

 Hm, it's tied to key generation so having the arg be next to
 KeyType:KeyBlob sort of makes sense to me (the only reason why it's not
 grouped with that arg is to avoid adding restrictions to the serialized
 blob beyond "no whitespace").

 Maybe something like: `[SP "Flags=" Flag *("," Flag)]` might be even
 better here, with `DiscardPK` being one of the flags, if it were to be
 non-positional?

 > Out of curiosity why does DEL_ONION disavow knowledge of hidden services
 not made by this controller connection? I'm guessing there's security
 reasons behind it but not sure offhand what they are.
 >
 > Presently the controller has full access over adding/removing hidden
 services. Unless I'm missing something with this change we're explicitly
 making use cases like "Connect to the control port and shut down all
 existing hidden services" impossible.

 I made the decision to tie HSes added this way to the controller
 connection to ensure that things get cleaned up if the application ever
 terminates abruptly, misbehaves, etc.  My rationale here currently is
 that, if the use-case you envision was allowed, there will be applications
 out there that blindly connect and kill off all hidden services, even ones
 that they shouldn't in the name of cleanup.

 We could add something like a `Detach` flag that overrides this behavior,
 and expanding `DEL_ONION` to be able to kill off HSes associated with the
 control port along with Detached ones (along with `LIST_ONIONS` that
 provides a list of ServiceIDs for such a purpose).  The code here would be
 easy, and is actually a reasonable argument for switching to the
 `Flags=DiscardPK,Detach` type syntax.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6411#comment:37>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs