Re: [tor-bugs] #14847 [Tor]: Controller: add a command to fetch HS descriptor from HSdir(s)

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

#14847: Controller: add a command to fetch HS descriptor from HSdir(s)
-----------------------------+----------------------------------------
     Reporter:  dgoulet      |      Owner:  dgoulet
         Type:  enhancement  |     Status:  needs_review
     Priority:  normal       |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  SponsorR tor-hs controller
Actual Points:               |  Parent ID:  #3521
       Points:               |
-----------------------------+----------------------------------------

Comment (by dgoulet):

 Replying to [comment:11 arma]:
 > Replying to [comment:9 dgoulet]:
 > > Ok, with all the comments above, here is a much simpler version.
 > >
 > > See branch {{{ticket14847_03}}}.
 >
 > What's the reasoning for the cache=yes or cache=no part? That is, why
 not just let rend_cache_store_v2_desc_as_client(() look at the hsdesc you
 get back and decide whether to keep it based on whatever rules it uses now
 ("I don't have a newer one, etc")?

 The original idea was to give a choice to the user to keep the fetched
 descriptor or not. However, if we go with a new HSDESC_* event to dump the
 content when it arrives, the "cache=" part could be removed and by default
 keeps the latest.

 >
 > I think to do the async thing here we'll want to extend the HSDESC event
 to just tell you the descriptor right then. Otherwise there's a three step
 process ("initiate the launch", "notice the event", "getinfo the
 response"), and if you initiate a bunch of launches, and then get a bunch
 of events, you'll only be able to getinfo one of them, and you might not
 even know which one it was, etc.
 >
 > (Whether you extend the HSDESC event always, or add a separate
 HSDESC_AND_DUMP event, or what, is a matter of taste that I will leave to
 you and Nick if you like this approach.)

 I'm not too familiar what are the best practices but could we do something
 like this with the EXTENDED events feature?

 {{{
 C: SETVENTS HS_DESC DUMP=yes
 [...]
 S: 650 HS_DESC RECEIVED ...
 S: 650 HS_DESC EXTENDED DUMP xyz.onion
 <dump here>
 }}}

 >
 > Now that I think about it, there may also be some adventure here with
 all of the implicit "oh a failure just happened, that means I should
 launch this other action" logic in hsdesc fetches. Maybe this is a good
 time to clean up some of that logic, or maybe it will turn out to be
 easier than we think to work with it. Or I guess option three is that this
 will just be no fun. :)

 I know... this is why I want this command accepted asap so I can start
 working on it. The HS fetch code is very "monolithic" in a way that it's a
 big block that does a lot of diffrent things. It would need to be much
 more modularized so we can cherry-pick the actions we need for this
 command and not really go through the normal process of fetching a
 descriptor right now.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14847#comment:14>
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