I have noticed that since the release of version 0.2.4.18-rc - 2013-11-16, Attempts to fetch v2 rendezvous service descriptor are failing. The issue seems to get worse as many people are updating their clients.
The calculation of decriptor ids based on specification in rend-spec.tx <descriptor-id = H(permanent-id | H(time-period | descriptor-cookie | replica))> doeesn't seems to be correct anymore. All 6 responsible hidden services directorates return 404 to a GET request for /tor/rendezvous2/<base32_encode[descriptor-id]>
I search through the tor source for the release version (0.2.4.18-rc - 2013-11-16) in rend_compute_v2_desc_id and rend_client_refetch_v2_renddesc but failed to notice any significant change. Could any member of the dev team respond to to this?
Frank Young pfcodes@gmail.com writes:
I have noticed that since the release of version 0.2.4.18-rc - 2013-11-16, Attempts to fetch v2 rendezvous service descriptor are failing. The issue seems to get worse as many people are updating their clients.
The calculation of decriptor ids based on specification in rend-spec.tx <descriptor-id = H(permanent-id | H(time-period | descriptor-cookie | replica))> doeesn't seems to be correct anymore. All 6 responsible hidden services directorates return 404 to a GET request for /tor/rendezvous2/<base32_encode[descriptor-id]>
I search through the tor source for the release version (0.2.4.18-rc - 2013-11-16) in rend_compute_v2_desc_id and rend_client_refetch_v2_renddesc but failed to notice any significant change. Could any member of the dev team respond to to this?
You need to use BEGIN_DIR: https://gitweb.torproject.org/torspec.git/blob/HEAD:/tor-spec.txt#l1364
HSDirs have been using solely BEGIN_DIR for a while. I'm not sure why, maybe so that the plaintext HTTP requests and responses are not sniffable by the adversary. There was also a ticket on trac somewhere that I can't find now.
Thanks for the headup but it is not that. Anyway, as posted in my last post, i have fixed the issue.
thanks
I have found out the issue, it relates to fixs made for time_t variables in an earlier version of tor. Microsofts changes of time_t from 32bit to 64bit caused you guys to stop the earlier assumptions that time_t will be negative sometimes. It broke my implementation but i have fixed it now. I think it is important to give technical details on every changes made instead of just saying it in the changelog file.
thanks