Re: [tor-dev] regarding control spec for hidden service descriptor

[grarpamp <grarpamp@xxxxxxxxx>]

>> # HS descriptor related extension to getinfo event:
>> GETINFO desc/hs/n.onion [network]
>>
>> n.onion fromcache <which hsdir served it to us>
>> n.onion fetchok <which hsdir served it to us>

> I guess that <which hsdir served it to us> is not used in this case.

Yes, it is / should be. It may require a bit of extension to the structure
holding the descriptor to carry it around. But it is the same hsdir
that is logged in debug mode upon successful fetch.

>> n.onion fetchfail <why>
>
> Nitpicking again, but instead of the 'fetchfail' message I would maybe
> use the error codes of the control port. For example, if the fetch
> fails I would send back a 551 or 552 error with the <why>. AFAIK
> that's how GETINFO helpers should signal error conditions.

Similarly, this is the error cause returned / logged from the
descriptor fetching routine. Using port codes would require
both some documented mapping of fetch routine error cause
to port code, and post control port code lookups... redundant.
And be subject to further disarray when descriptor version
changes. Just pass it through as a returned data field. You
may need to enhance the structure to carry a NULL descriptor.
I believe this is also currently logged in debug mode, for which
it would place in that structure.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev