Re: [tor-bugs] #14846 [Tor]: Controller: retrieve an HS descriptor of a service run by a user

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

#14846: Controller: retrieve an HS descriptor of a service run by a user
-----------------------------+----------------------------------------
     Reporter:  dgoulet      |      Owner:  dgoulet
         Type:  enhancement  |     Status:  new
     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:4 arma]:
 > Replying to [comment:3 dgoulet]:
 > > > That said, keeping a copy of the last descriptor you encoded doesn't
 sound too hard, and would make this ticket pretty easy to implement.
 > >
 > > Either that or we recreate (without uploading) and dump it?
 >
 > Careful! Recreating it will sometimes make a different descriptor than
 the one you published. For example,
 > {{{
 >   time_period = get_time_period(now, period, service_id);
 > }}}
 > so you could even end up with a different descriptor_id than the one you
 published.

 Yes it can but that's kind of the point of getting the latest possible
 descriptor when you query Tor with a configured HS though, as you mention
 it, might not be the one that is currently published (but soon to be). I'm
 not sure here which one is the more useful, the latest or the one
 published (or both)?...

 >
 > > > Makes me wonder if we also want an event for publishing hsdescs
 (else, how can you know that the answer to this getinfo has changed).
 > >
 > > Maybe adding an Action `UPLOADED` to the `HS_DESC` event?
 >
 > Interesting idea. So far all the HS_DESC events are about clients
 visiting a hidden service, right? If so, would we want to jumble in the
 events from operating a hidden service too, or does that merit a new event
 type?

 It's only client yes but since tor is a "all in one daemon", an HS service
 can also be a client for a user. I don't see how a client at some point
 can upload an HS desc thus this action would be quite specific to the HS
 service subsystem.

 I guess it comes down to how we want to "perceive" the HS_DESC event as a
 possible event regardless of the subsystem at hand or should it be
 specific to a subsystem, here the client HS part. (The spec does not
 really define the "owner" of an HS_DESC event, sounds we could actually
 clarify that.)

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