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