1. 7
  1.  

    1. 2

      Everything is broken and low-hanging fruit is everywhere.

      Harsh but true, at least in my experience. And ironically, bugs may resurface with new features being introduced.

      Their approach to include the source files directly, redefining function names using #defines as necessary truly fits the “hacksaw” comparison!

      Their point (5) regarding creating a made-to-fit buffer for testing so ASan can do its work properly sounds pretty subtle to me, and like something that should be changed upstream.

      And using memfd file descriptors for functions that require a path name as argument (their point (7)) is also pretty cool. TIL!

      Overall, I get the impression that their fuzzing tips are really geared towards fuzzing manually, not so much towards CI integration.

      1. 1

        Overall, I get the impression that their fuzzing tips are really geared towards fuzzing manually, not so much towards CI integration.

        Why do you say that? The tips are about building fuzzers not about running them.

        1. 3

          Yes, that’s true! I read it such that these tips help you quickly build fuzzers to find those low-hanging fruits and get them fixed. But for CI integration I imagine I’d rather change the structure of the program such that I don’t need a “hacksaw” to get to the juicy parts, and maybe integrate the whole thing into my build system so I can scale building fuzzers easily.