Spec conformance issues on get_next_token() reported by outofwords
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]