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

[George Kadianakis <desnacked@xxxxxxxxxx>]

Qingping Hou <dave2008713@xxxxxxxxx> writes:

> On 09/02/2013 05:01 AM, grarpamp wrote:
>> On 9/2/13, grarpamp <grarpamp@xxxxxxxxx> wrote:
>>>> https://trac.torproject.org/projects/tor/ticket/8510
>> 
>>> 'fetchfail' or 'fetchok'
>> 
>>> These two status need extended fields
>>> fetchfail <why>
>>> fetchok <which hsdir served it to us>
>> 
>> 'fromcache' also needs <which hsdir served it to us>
>> _______________________________________________
>> tor-dev mailing list
>> tor-dev@xxxxxxxxxxxxxxxxxxxx
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>> 
>
>
> Thanks for your suggestion! Following is my summary for the stuffs we
> need to
> add, let me know if I missed anything :)
>

Thanks!

I'm nitpicking a bit below just to give you a taste of some of the
things that you should think about when you start editing torspec.

>
> # Asynchronous events for hs descriptors:
>
> HS_DESC SP REQUESTED SP OnionAddress SP DescptorID SP AuthType SP HsDir

If my Tor needs an HS descriptor and requests it, will this event
trigger once for each HSDir directory connection? Or will it only
trigger once (what is the 'HsDir' field then?)?

Also, do you know the AuthType beforehand (at the time of requesting
an HS descriptor)? Or do you learn it afterwards?

> HS_DESC SP RECEIVED SP OnionAddress SP DescptorID SP AuthType SP HsDir
> HS_DESC SP PUBLISHED SP OnionAddress SP DescptorID SP AuthType SP HsDir
>

What is the 'HsDir' field here? Is it a list of all the HSDirs we
published our descriptor on?

>
> # HS descriptor related extension to getinfo event:
>
> request:
>
> GETINFO desc/hs/n.onion [network]
>
> where network is an optional argument, if given, will force refetch of HS's
> descriptor.
>
> response:
>
> First line with one of following headers:
>
> n.onion fromcache <which hsdir served it to us>

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

> 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.

> n.onion fetchok <which hsdir served it to us>
>
> Then prints out cached descriptor labels and data fields, one line per
> field.
> If cache is NULL, print empty body.
>
>
> example:
>
> C: GETINFO desc/hs/n.onion
> S: 250+desc/hs/n.onion=
> S: n.onion fromcache
> S: [Descriptor for n.onion]
> S: .
> S: 250 OK
>
>
> Another question:
>
> How can I submit a patch to torspec repo? Create a ticket and attach my
> patch?
>

Yep, that's a good way to submit a patch.
(Even better, if you have a public git repository for torspec (github
or something), make a branch with your mods and post a link to it in
the trac ticket.)

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev