[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-bugs] Re: #1270 [Tor - Tor client]: Spec conformance issues reported by outofwords



#1270: Spec conformance issues reported by outofwords
-------------------------------+--------------------------------------------
  Reporter:  Sebastian         |       Owner:  nickm             
      Type:  defect            |      Status:  assigned          
  Priority:  minor             |   Milestone:  Tor: 0.2.2.x-final
 Component:  Tor - Tor client  |     Version:  0.2.1.22          
Resolution:  None              |    Keywords:                    
    Parent:                    |  
-------------------------------+--------------------------------------------

Old description:

> I scrapped this from IRC. Don't really have time to clean it up or
> implement any of the proposed fixes atm, but so we don't forget:
>
>  ideafix http://paste.debian.net/62206/
>  for extrainfo wrongly fix. yet one try.
>  http://paste.debian.net/62207/ ideafix for sure.
>  nah, yet cert need to fix, but hopes idea is trasmitted.
>  and rend stuff.
>  get_next_token() have a fragile logic, even if it "We go ahead whether
> there are arguments or not, so that tok->args is always set" while *s ==
> eol. tok->args = memarea_memdup(area, args, 0x00) for such case. so any
> access to args[0] is invalid in theory.
>  if any try to access anything from tok->args[] with tok->n_args=0, it
> clearly should crash. bug should not be hidden. so here clarified func
> http://paste.debian.net/62216/
>  hah nah not such.
>  http://paste.debian.net/62219/ clear fix of get_next_token()
>  no, it's incomplete. ignore it.
>  http://paste.debian.net/62245/ I don't know why it need, but my brain
> can't release it.
>  Fix a spec conformance issue (complete version):
> http://paste.debian.net/62253/
>  "ArgumentChar ::= any printing ASCII character except NL." space is
> printing character, isn't?
>  so "KeywordLine ::= Keyword NL | Keyword WS ArgumentChar+ NL" means
> Keyword space space space NL is valid isn't?
>  then "router-signature" NL Signature NL means that "router-signature
> \n" valid. is true?
>  and "router-signature\t\n" is not valid. ouch.
>  so code is unrealy hard to properly implement of such spec.
>  I am give up with tor
>
>  Please do clarify work for the spec or for the code about ArgumentChar.
> Can be "\nrouter-signature     \n" valid? If not here is my idea for fix
> the code. http://paste.debian.net/62277/
>

> [Automatically added by flyspray2trac: Operating System: All]

New description:

 I scrapped this from IRC. Don't really have time to clean it up or
 implement any of the proposed fixes atm, but so we don't forget:

  ideafix http://paste.debian.net/62206/
  for extrainfo wrongly fix. yet one try.
  http://paste.debian.net/62207/ ideafix for sure.
  nah, yet cert need to fix, but hopes idea is trasmitted.
  and rend stuff.
  get_next_token() have a fragile logic, even if it "We go ahead whether
 there are arguments or not, so that tok->args is always set" while *s ==
 eol. tok->args = memarea_memdup(area, args, 0x00) for such case. so any
 access to args[0] is invalid in theory.
  if any try to access anything from tok->args[] with tok->n_args=0, it
 clearly should crash. bug should not be hidden. so here clarified func
 http://paste.debian.net/62216/
  hah nah not such.
  http://paste.debian.net/62219/ clear fix of get_next_token()
  no, it's incomplete. ignore it.
  http://paste.debian.net/62245/ I don't know why it need, but my brain
 can't release it.
  Fix a spec conformance issue (complete version):
 http://paste.debian.net/62253/
  "ArgumentChar ::= any printing ASCII character except NL." space is
 printing character, isn't?
  so "KeywordLine ::= Keyword NL | Keyword WS ArgumentChar+ NL" means
 Keyword space space space NL is valid isn't?
  then "router-signature" NL Signature NL means that "router-signature
 \n" valid. is true?
  and "router-signature\t\n" is not valid. ouch.
  so code is unrealy hard to properly implement of such spec.
  I am give up with tor

  Please do clarify work for the spec or for the code about ArgumentChar.
 Can be "\nrouter-signature     \n" valid? If not here is my idea for fix
 the code. http://paste.debian.net/62277/


 [Automatically added by flyspray2trac: Operating System: All]

--

Comment(by nickm):

 Now see branch "get_next_token_v2" in my public repostory, rebased to work
 against current master.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1270#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online