Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96685
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Stanislav Malyshev'" <smalyshev@gmail.com>,
	"'PHP Internals'" <internals@lists.php.net>
References: <3a5408bc-b71d-920c-45e4-b9be02350b6c@gmail.com> <01a901d22e06$ca4e3450$5eea9cf0$@belski.net> <d8d88f58-a632-45d6-ba02-b9f9582eb30b@gmail.com>
In-Reply-To: <d8d88f58-a632-45d6-ba02-b9f9582eb30b@gmail.com>
Date: Tue, 1 Nov 2016 02:39:19 +0100
Message-ID: <01a701d233e0$c6505510$52f0ff30$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQIw/dPx2uTzgX7O3dl7/zFSJ2INJgGCQLnsAkXn9Iuf5gQmEA==
Content-Language: en-us
Subject: RE: [PHP-DEV] Security issue handling
From: anatol.php@belski.net ("Anatol Belski")

Hi Stas,

> -----Original Message-----
> From: Stanislav Malyshev [mailto:smalyshev@gmail.com]
> Sent: Sunday, October 30, 2016 11:01 PM
> To: Anatol Belski <anatol.php@belski.net>; 'PHP Internals'
> <internals@lists.php.net>
> Subject: Re: [PHP-DEV] Security issue handling
>=20
> Hi!
>=20
> > release. Say, as we do it now, we tag two days before. It could be
> > defined, for example, that any security patches intended for release
> > inclusion, have to be merged into security repo, ported and tested 5
> > days before tag. Fe Thursday/Friday in week before final, it is
>=20
> That's nice but most patches right now are in security repo long =
before, and still
> nobody reviews them. Also, the reality is that I mostly work on =
patches on
> weekends, so that means either any of the patches I work on one of the =
4
> weekends can't be merged for a month or we need a better model.
>=20
That was the exact idea. I, at least, am going for ports a week before =
release, as mentioned. But even otherwise - having a cut a week before =
is what addresses the QA concerns in first place, that Remi and you also =
expressed. Say, if there is a vulnerability, which is not disclosed and =
present for years - while it's not good it'd go into release a month =
later, still it's better than a possible another bug introduced because =
of the last minute or unreviewed patch. It wouldn't of course affect a =
situation, where a fix is urgent.=20

> > Maybe, it'd make sense also to have a finer privileges system on BT.
> > Fe, several people could be allowed to review some selected tickets =
on
> > BT, without having the actual security repo access. Say, any =
security
> > team participant would be able to assign some new reviewer to a
> > particular ticket.
>=20
> That probably can be done, but let's say it's done now. Who I would be =
assigning
> to the new issue? I have no idea who wants/can review it.
>=20
What I had in mind, in first place involving the karma holders and ext =
maintainers. Like Jakub and Christoph already expressed the willingness =
to do fixing regularly, other active core commiters or any other trusted =
person could be asked to help on demand. Of course, we don't know how it =
would work, until it's started to be done this way. It could be, that =
asking some random active and known contributor to review just one patch =
would be more effective, that asking the same person to do it regularly =
as in security team.=20

> > OFC it'd be ideal to have some karma holders to participate. And
> > another option, which is IMHO eligible - we could invite several
> > reporters. There is already a couple of people, who regularly report
> > security issues and keep them confident until they're publicly
> > disclosed. IMHO it is a good base for trust.
>=20
> The reporter is asked to review the patch anyway. I don't think I feel
> comfortable inviting other reporters - unless I know who they are, =
which right
> now is not true for most of them.
>=20
> > Also, having people even without iternals knowledge, that could just
> > test, were useful as well. For that case, we could find more people
> > even without php-src karma or access to the security repos. =
Providing
> > some test binaries only wouldn't be that hard. In that case, while =
we
> > couldn't disclose the actual security issues, the "blind testing"
> > could have a positive effect in determining unforeseen issues, too.
>=20
> Hmm I don't know. I certainly won't have time to arrange binary builds =
usable
> for people with no dev knowledge, but if somebody volunteers to =
organize it,
> fine. But that again means a) disclosing security issues to people =
before fix is
> available, so this should be people we know and b) that should be =
people that
> want to commit substantial amount of time.
>=20
Just as a loud thought - when seeing same person makes authentic =
reports, using good tools, there's no premature disclosure, so it is a =
meaningful behavior. What i've mentioned earlier and plea for - it were =
great to have a constant security response team, some structure that =
allows to ensure fixes, reviews and QA on security patches regularly. It =
is absolutely clear, that it is much better to involve only people with =
the karma and contributing actively. But I've an impression, and see it =
on my example as well :), that people currently contributing on the =
constant frequency, have not necessarily interest or time on pure =
security patches handling. IMHO it indeed makes sense what Rasmus said, =
to send a dedicated call for security team participation and see what =
happens. And as a fallback, if no enough reaction is to see, check other =
ways to achieve more QA. With the binary only testing - it's likely that =
good people are to find in the PHP projects, and I could take on the =
builds but would require a machine where it could be done and shared.

Regards

Anatol