Re: [tor-bugs] #20169 [Core Tor/Tor]: hs_desc, hs_desc_content - BAD_DESC|NOT_FOUND

[Tor Bug Tracker & Wiki]

#20169: hs_desc, hs_desc_content - BAD_DESC|NOT_FOUND
-+-
 Reporter:  grarpamp |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, tor-hs, tor-control,   |  Actual Points:
  usability  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  spec, tor-hs, tor-control => tor-spec, tor-hs, tor-control,
 usability


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20169 [Core Tor/Tor]: hs_desc, hs_desc_content - BAD_DESC|NOT_FOUND

[Tor Bug Tracker & Wiki]

#20169: hs_desc, hs_desc_content - BAD_DESC|NOT_FOUND
---+--
 Reporter:  grarpamp   |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:  Tor: 0.2.8.7
 Severity:  Normal | Resolution:
 Keywords:  control, spec, tor-hs  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dgoulet):

 * keywords:   => control, spec, tor-hs
 * priority:  Medium => Low
 * type:  defect => enhancement
 * milestone:  Tor: 0.2.9.x-final => Tor: 0.2.???


Comment:

 Moving that out of 029 for now as I doubt we'll be able to squeeze this in
 in time for the October release. If a spec and code patch comes in though,
 I'll be more than happy to consider it!

 I do like the idea of printing the unparseable descriptor in the case of
 `BAD_DESC`!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20169 [Core Tor/Tor]: hs_desc, hs_desc_content - BAD_DESC|NOT_FOUND

[Tor Bug Tracker & Wiki]

#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: 0.2.8.7
 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
 the HS_DESC_CONTENT line as CONDITION=BAD_DESC.

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

 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: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs