On 30/01/2015 1:27 a.m., Niels Möller wrote:
Amos Jeffries writes:
I have added a fuzz tester that runs a set of randomly generated strings past the default encoder and decoder, then the extended one.
Nice. It would be good with a couple of short manual examples as well. A pity that RFC 4648 doesn't include any testvectors for base64url. (Or am I missing something? Simon?)
- if you have a better random generator you would like to use please
let me know where to find a code example or docs for it.
I'd suggest using lfib_knuth generator in nettle. And maybe you already to that, but it's good to randomize also the length of the data.
Aha. Thank you. I missed that in the docs. (Kudos to the person who designed that function set, its probably the most lovely I've seen in a long while.)
Yes I was randomizing the length, which actually turned out to be the assert problem. rand()%N-4 [vs. rand()%(N-4)] will eventualy become negative and break tha stack. The consistency in the face of changing seed values has also confirmed my aversion to staying with rand() for the final version.
It would seem worthwhile adding some additional compiler flags to add things like stack protectors specifically for the unit tests to catch other mistakes like mine.
The test and the coders seem to be working fine. Except that when I increase the *count* of fuzz test run it asserts regular as clockwork on the 950th loop:
base64-test: base64-encode.c:96: _base64_encode_raw: Assertion `in == src' failed.
This needs investigation. Have you run the tests under valgrind? ("make check EMULATOR='$(VALGRIND)'")?
Do you wish me to remove base64_encode_group entirely?
No, not at this time (it's used in one place, in the unfinished openpgp code).
Regards, /Niels
Okay. v3 patch about to follow.
Amos