On Wed, 2017-06-28 at 17:48 +1000, Daniel Axtens wrote: > Hi all, > > I fuzzed parsemail with python-afl/afl-fuzz. > > Predictably, it did not hold up well. Nothing major, just a bunch of > edge cases. Date parsing held up particularly poorly. > > Currently, if we hit any of the errors this patch set fixes, the > entire mail will be rejected. With this patch set, the emails have a > much better chance of surviving. This is helpful for us - we have > previously had bug reports where a stray mail has been rejected due to > a corrupt header, which is suboptimal. > > Test cases are included. They may not email particularly well so I > have also put them up on my github as a signed tag: > https://github.com/daxtens/patchwork/releases/tag/fuzz-testing > > For the interested, the bulk of the fuzzing was done on an AWS cloud > instance, using something quite similar to the standard docker-compose > setup. Several hundered thousand executions were done - nowhere near > what I'd like but I can't seem to get execution speed above about 1 > execution per second. If I was able to confidently mock out the db or > extract the parser out of the django framework it would go faster, but > both of those were a bit more than I was easily able to do. I also > picked up some bugs when interfacing with the db (patch 7) so I feel > like this approach was vindicated. > > I also included a patch to allow people to replicate my setup. It's > not really ready to merge and I'm not convinced it's really necessary > as it's not a lot of work to replicate.
I've merged all patches except 08/10 and 10/10. The former needs a bit of rework, and the latter can wait til 2.1 at least. I can tag either rc5 or final once 08/10 is resent. Stephen _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork