error: partial base64 value left over
Peter Rathlev
peter at rathlev.dk
Tue Jan 25 23:45:48 UTC 2011
On Tue, 2011-01-25 at 12:03 +0100, Peter Rathlev wrote:
> It happens in common/parse.c, but I can't figure out exactly why that
> happens. It could be the tokenization in common/conflex.c.
I tried taking a look at the source. I'm a total newbie concerning C,
but the problems seems to be in read_num_or_name (conflex.c:499 for
dhcp-3.1-ESV, in dhcp-4.2.0-P2 it's conflex.c:676 but the problem is the
same):
507 c = get_char (cfile);
508 if (!isascii (c) ||
509 (c != '-' && c != '_' && !isalnum (c))) {
510 if (c != EOF) {
511 cfile -> bufix--;
512 cfile -> ugflag = 1;
513 }
514 break;
515 }
The '+' at position 73 in the base64 string doesn't pass the test in
line 508/509, whereafter the main loop in the function breaks.
And cfile->cur_line is alread \0-terminated; get_char (conflex.c:109 in
3.1-ESV) continually moves the termination of cur_line, but not after
cfile->lpos (position in line) moves beyond 80. Thus only the first 80
characters are returned.
Including "&& c != '+' " in the test on line 509 seems to fix the
problem, but I'm not sure that's the "right" solution. And the quoted
string works since "read_string" doesn't use "isalnum" or similar, only
terminating at the ending double quote.
I'm still puzzled why only the example string doesn't work:
secret XQhFIJF1HGrlAZKQbIu2VBZxLGXbjEI5Y0VMw0zzoiEyKKw1U/1yTgTVU2nKVjnUdnRHa+p66+NO+iwteSPRrg==;
when several randomly generated test-strings do work, all including a
'+' towards the end, also one at the same place:
secret scFAcHjy4M8lYkpnEu3NGPZHt98ibQ7OoFJBY3vtjtp/KCSDKPKDcRnPsT9LCYFYoM8LhvaXe+2YWcSgm1WUQA==;
secret ACaNKKbYkDMpyrQA6kIXp2o3EoizLtx7XNdzuRz+lqbWpNNoZIVpbtp89qZHMwAJp+jN2x4Bv60a6oo3CKo/ks4u;
secret Jeai+cnylEnRMrrAhvs7wzeiaIfYsRywYuIdAi8wrXAQ6jXvVfpgO0WVZfI/pXwgR9xDnaKK/QVtKFFHQCrjpM+e;
secret 2HHBCvLJ3OWqlAvOTPCvhN3KR5EODqPcSBgRqt7Q6ULSYZGJ2EF7HFxp6PlHc/u6nOxAWSbE2adz+gQKWt7wp8by;
secret 4/JUFaXwd6ruQYafxGYkkFEyuY2bi/zyhcmOBlW8fA7E9kid4qTI/6tvNswjAUHNJHlCM2n0Um3UU6gEa+disXMF;
secret HKlApJXvSMzbX9iFb7UmW+pmLfdc+twUR7FZKNXhb8/kCMi3v/Cj/gh2OIvHwktK/bE9qLtz48+ja5H0RCRAkw==;
secret 93k4/LJ7TZP39S/d6LnUcU7o9577wE4SM92CG9UmntE72HAL5ucbyLyUsKeYLpaKGH1Ucz8bwLXSmFvGi2+IWQ==;
secret /xTMM8cXWfbZjEtRp+mGK11yCDPJi+fMX+qH27eNMYmnOQtRBvyIDZUm+82z6hllNinbiej+cWCSB/0oGZ583g==;
secret gGk3bT3fYFcJll6I2ASMKgdFznysIXvq70tie7Oeeoh2lfGNZ8oLo3j3/Ue9hCCCGw4o1JDVlHs++2kh1L7QsQ==;
secret bqLzggotx6atmS/LfvwYnr8/N5k2WtoyVTMCoIYREgu0eJ3S6nEibNRFsIKt0fo/LXNwScrBX6hRI+Z848hUuA==;
secret kO7c1dF4PW/zJPCxNZzXmCTe+njq0ge6pa395DzoVbV/xTHabc7EwZ+Jr+hUz0rbu1h3Dipu+/eMjjd3U0nLDg==;
Which means I probably haven't understood the real problem.
--
Peter
More information about the dhcp-users
mailing list