Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106361
Message-ID: <0f60226d2d6aaf9fc044644a16c0ad7390ed3752.camel@schlueters.de>
To: bishop@php.net, Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Date: Wed, 31 Jul 2019 00:15:39 +0200
In-Reply-To: <CAEYWF=4iA_k9hr=ZA4kP1C5PA0gEpJS4WpTdYF1GFMP9y27Q2g@mail.gmail.com>
References: <35af7db3-5cba-fe59-1d04-960eacb5aba7@gmail.com>
	 <CAEYWF=4iA_k9hr=ZA4kP1C5PA0gEpJS4WpTdYF1GFMP9y27Q2g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Merging fuzzing SAPI into core
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Tue, 2019-07-30 at 13:28 -0400, Bishop Bettini wrote:
> 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.


We could grant access to the respective SAPI directory only. Also this
is non-production code so even if merged rules can be relaxed. Only
rule we have no real flexibility over is the merge requirement. (not
observing that would cause trouble for others)

I am also not sure having this independent makes it simpler for
outsiders to contribute. You maybe ease the submission process, but
setting it up becomes harder as you need to clone to repos, put it in
the right place, make sure you are in compatible branches (on next PHP
7 like API change this might become relevant, maybe even sooner as it
goes into different extension's APIs where we observe BC a bit less)

I think merging it into PHP makes the most sense, also for signaling to
the outside that we care about security by having fuzzing routines as
core part of the thing.

johannes