regarding control spec for hidden service descriptor
Hi all, I am currently working on ticket 8510: https://trac.torproject.org/projects/tor/ticket/8510 However, I notice that in the control spec, there is no event related to hidden service descriptors. Should we add a new event in the spec? For example, we can have something like the following: HS_DESC SP REQUESTED SP OnionAddress SP DescptorID SP AuthType SP HsDir SP Any thoughts? Cheers, qp
I am currently working on ticket 8510: https://trac.torproject.org/projects/tor/ticket/8510
However, I notice that in the control spec, there is no event related to hidden service descriptors. Should we add a new event in the spec?
For example, we can have something like the following: HS_DESC SP REQUESTED SP OnionAddress SP DescptorID SP AuthType SP HsDir SP
Any thoughts?
The above basics seem fine. The controller also needs to accept queries for onion descriptors, eg: getinfo n.onion [network] If the descriptor is not cached, or it is cached but it is just now checked at query time and found to be expired, set cache to NULL, then fetch and cache it. If the descriptor is cached and not expired, allow an optional 'network' flag to force a refetch from the network and cache it again, but do not update cache unless the refetch was successful. Now the current descriptor is cached or NULL, decode and print all the fields contained within it (all the v2 fields for example). I would suggest one line per field. 'getinfo ...' always prints an additional special return header field line: 'n.onion status <status>', where <status> is 'fetchfail' or 'fetchok' or 'fromcache' depending on above modes/results. and also always prints the cached descriptor labels and data fields (if cache is NULL, just print empty date fields).
On 9/2/13, grarpamp <grarpamp@gmail.com> wrote:
'fetchfail' or 'fetchok'
These two status need extended fields fetchfail <why> fetchok <which hsdir served it to us>
On 09/02/2013 05:01 AM, grarpamp wrote:
On 9/2/13, grarpamp <grarpamp@gmail.com> wrote:
'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@lists.torproject.org 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 :) # Asynchronous events for hs descriptors: HS_DESC SP REQUESTED SP OnionAddress SP DescptorID SP AuthType SP HsDir HS_DESC SP RECEIVED SP OnionAddress SP DescptorID SP AuthType SP HsDir HS_DESC SP PUBLISHED SP OnionAddress SP DescptorID SP AuthType SP HsDir # 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> n.onion fetchfail <why> 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?
Hi Qingping. I'll largely leave this to Nick, but here's a ticket concerning this exact topic... https://trac.torproject.org/projects/tor/ticket/8891 Personally I'm a little interested in it since this would make it worthwhile for me to add a hidden service descriptor parser to stem. I suspect this will need a proposal. As for a spec patch, that would certainly be welcome once this has been added to tor (we want to update them together). Cheers! -Damian
On 09/03/2013 10:02 AM, Damian Johnson wrote:
Hi Qingping. I'll largely leave this to Nick, but here's a ticket concerning this exact topic...
Thanks for pointing me to the ticket :)
Personally I'm a little interested in it since this would make it worthwhile for me to add a hidden service descriptor parser to stem.
Yep, that will be very handy.
I suspect this will need a proposal. As for a spec patch, that would certainly be welcome once this has been added to tor (we want to update them together).
No problem, I will start with async events first and will send out patches to both tor and torspec in separate tickets.
Qingping Hou <dave2008713@gmail.com> writes:
On 09/02/2013 05:01 AM, grarpamp wrote:
On 9/2/13, grarpamp <grarpamp@gmail.com> wrote:
'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@lists.torproject.org 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.)
On Tue 03 Sep 2013 01:25:55 PM EDT, George Kadianakis wrote:
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.
Thanks for all the feedback!
# 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?)?
It will be triggered for each HSDirs directory connection, i.e. every time an real request is sent out. HsDir here means the which hsdir directory serves the descriptor, a typical example can be: "FingerPrint at IP" I will add explanation for each filed in the spec.
Also, do you know the AuthType beforehand (at the time of requesting an HS descriptor)? Or do you learn it afterwards?
IIRC, it should be known beforehand, but I need to double check this ;p
# 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.
Hm, you are right, I am not sure whehter we can even get this information from cached descriptor.
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.
Agree, I totally missed this part, will adjust this part.
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.)
Yes, by "patch", I mean pullable public git branch ;p It will be in github. Thanks, qp
# 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.
participants (4)
-
Damian Johnson -
George Kadianakis -
grarpamp -
Qingping Hou