#20169: hs_desc, hs_desc_content - BAD_DESC|NOT_FOUND
 Reporter:  grarpamp      |          Owner:
     Type:  defect        |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |        Version:  Tor:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:

Comment (by grarpamp):

 Torspec hs_desc REASON...
 - "BAD_DESC" - descriptor was retrieved, but found to be unparsable.
 - "NOT_FOUND" - HS descriptor with given identifier was not found.


 The controller prints both of these cases as a single new line.
 Which given the two different cases, should print differently, with
 torspec fixed to match.

 For BAD_DESC, HS_DESC_CONTENT should be the retrieved data, regardless
 if it is unparseable, even if empty. This case should be tagged in

 For NOT_FOUND, HS_DESC_CONTENT should be truly empty ie: 'no new
 line', and tagged CONDITION=NOT_FOUND.

 Also, HS_DESC_CONTENT for these is not setting HSAddress to UNKNOWN
 per torspec. That is good because this deviance allows parsing out
 the content in all cases by the onion string. Thus this part should
 be removed from torspec.

 Obvously in BAD_DESC case the descriptor should not be propagated
 further into the client for any actual use beyond the fetching

 We want to see the retrieved but unparseable descriptor data. Not
 least of why is to determine parsing bugs, and any bugs / corruption
 located in the HSDir / client / network.

Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20169#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
tor-bugs mailing list

Reply via email to