Opened 6 years ago

Closed 6 years ago

#7533 closed defect (fixed)

AUTHDIR_NEWDESCS vaguely documented

Reported by: atagar Owned by:
Priority: Medium Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-auth spec
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The AUTHDIR_NEWDESCS events lack sufficient information for me to parse them. At present all the spec has is...

4.1.8. Descriptors uploaded to us in our role as authoritative dirserver

  Syntax:
     "650" "+" "AUTHDIR_NEWDESCS" CRLF Action CRLF Message CRLF 
       Descriptor CRLF "." CRLF "650" SP "OK" CRLF 
     Action = "ACCEPTED" / "DROPPED" / "REJECTED"
     Message = Text 

https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt#l1505

Questions that I have are...

  • What meaning does the "Message" have? What characters can it contain? Can it have newlines?
  • The Actions should have a description for what the actions mean, and say if new values are allowed or not.
  • What format does the "Descriptor" take? Is this a server descriptor? Microdescriptor? Router status entry? What version?

Child Tickets

Change History (2)

comment:1 Changed 6 years ago by nickm

Keywords: tor-auth spec added
Milestone: Tor: 0.2.4.x-final

comment:2 in reply to:  description Changed 6 years ago by nickm

Resolution: fixed
Status: newclosed

Replying to atagar:

The AUTHDIR_NEWDESCS events lack sufficient information for me to parse them. At present all the spec has is...

4.1.8. Descriptors uploaded to us in our role as authoritative dirserver

  Syntax:
     "650" "+" "AUTHDIR_NEWDESCS" CRLF Action CRLF Message CRLF 
       Descriptor CRLF "." CRLF "650" SP "OK" CRLF 
     Action = "ACCEPTED" / "DROPPED" / "REJECTED"
     Message = Text 

https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt#l1505

Questions that I have are...

I think I should have this cleared up in a1331ca69dc768709b53b104b243fca27320ae74

  • The Actions should have a description for what the actions mean, and say if new values are allowed or not.

For this, I added a statement in 4745fc3dbaf8253e96bf2a543d0140a60e6dba50 that if values are enumerated, and there isn't an explicit statement saying that new values will never be added, new values may be added. That should prevent snafus in the future.

Note: See TracTickets for help on using tickets.