Opened 3 years ago

Last modified 2 years ago

#20169 new enhancement

hs_desc, hs_desc_content - BAD_DESC|NOT_FOUND

Reported by: grarpamp Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.8.7
Severity: Normal Keywords: tor-spec, tor-hs, tor-control, usability
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Looking at a handful of HS descriptors...

setevents hs_desc hs_desc_content
hsfetch 2shgsl6ca3hwqnov

3 HSDirs - BAD_DESC
3 HSDirs - NOT_FOUND

All 6 print...
650+HS_DESC_CONTENT

.
650 OK

Child Tickets

Change History (7)

comment:1 Changed 3 years ago 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 empty and tagged
CONDITION=NOT_FOUND.

If RECEIVED and passed whatever parsing rules, set HS_DESC_CONTENT
CONDITION=OK.

Also, HS_DESC_CONTENT for at least BAD_DESC and NOT_FOUND is not
setting HSAddress to UNKNOWN per torspec. That is a good thing
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.

Last edited 3 years ago by grarpamp (previous) (diff)

comment:2 Changed 3 years ago by dgoulet

Keywords: control spec tor-hs added
Milestone: Tor: 0.2.9.x-finalTor: 0.2.???
Priority: MediumLow
Type: defectenhancement

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!

comment:3 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:4 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:5 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:6 Changed 2 years ago by dgoulet

Keywords: tor-control added; control removed

Unify "control" keyword to "tor-control".

comment:7 Changed 2 years ago by nickm

Keywords: tor-spec usability added; spec removed
Note: See TracTickets for help on using tickets.