On Sun, Jul 28, 2019 at 8:48 PM Stanislav Malyshev <smalys...@gmail.com> wrote:
> > As you probably know, we've been running PHP fuzzing under Google's > OSS-Fuzz[1] project for a while now (and found and fixed some bugs due > to it). > > This has been enabled by the PHP fuzzing API SAPI[2] which currently > lives in a separate repository. Since the setup is working pretty well > for a while now, I would like to propose to merge it into core > repository as a core SAPI, and make Travis CI setup build it as part of > the CI tests. > > This would ensure the fuzzing scripts are not broken by core changes > (happened several times recently) and would provide wider exposure to > the fuzzing setup we have, hopefully prompting extension authors and > other contributors to add more fuzzing modules to it, thus enhancing PHP > security and reliability. > > Are there any objections or suggestions about this? Do we need an RFC > for it? Note that this is only for master branch (only master is being > fuzzed now), though it would not be hard to port to other branches if > there's interest, the fuzzer should work on pretty much any recent > branch with small code changes. > I see benefit both ways. On the one hand, having the fuzzer and engine code together removes the effort of integrating the two, which (as you mention) makes it easier to extend and invoke. This is good for core and extension maintainers. On the other, I've found it refreshing working in a slender repo that doesn't have all the history and process rules. This is good for external (non-core and non-extension) collaborators, particularly allowing write access to those who wouldn't want or need write access to engine code. I lean toward the "keep it separate" option, since the process barriers are much smaller. Couldn't we update Travis to clone the repo, run the build/configure steps, then invoke the fuzzer as part of the make test phase? Or, how about the other way: setup Travis on the fuzzing repo to clone php/php-src:master, integrate it, and run? Either way, I don't think an RFC is applicable. To me, the fuzzer is a dev-dependency (in composer parlance) that doesn't surface to users.
