Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106351
MIME-Version: 1.0
References: <35af7db3-5cba-fe59-1d04-960eacb5aba7@gmail.com>
In-Reply-To: <35af7db3-5cba-fe59-1d04-960eacb5aba7@gmail.com>
Reply-To: bishop@php.net
Date: Tue, 30 Jul 2019 13:28:16 -0400
Message-ID: <CAEYWF=4iA_k9hr=ZA4kP1C5PA0gEpJS4WpTdYF1GFMP9y27Q2g@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000debdd2058ee95634"
Subject: Re: [PHP-DEV] Merging fuzzing SAPI into core
From: bishop@php.net (Bishop Bettini)

--000000000000debdd2058ee95634
Content-Type: text/plain; charset="UTF-8"

On Sun, Jul 28, 2019 at 8:48 PM Stanislav Malyshev <smalyshev@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.

--000000000000debdd2058ee95634--