Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96596 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 62262 invoked from network); 24 Oct 2016 14:56:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Oct 2016 14:56:32 -0000 Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error) X-PHP-List-Original-Sender: anatol.php@belski.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:42100] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D3/6F-28528-D112E085 for ; Mon, 24 Oct 2016 10:56:30 -0400 Received: by h1123647.serverkompetenz.net (Postfix, from userid 1006) id A4D21784A33; Mon, 24 Oct 2016 16:56:26 +0200 (CEST) Received: from w530phpdev (p57A87E2F.dip0.t-ipconnect.de [87.168.126.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by h1123647.serverkompetenz.net (Postfix) with ESMTPSA id 7BE067849D0; Mon, 24 Oct 2016 16:56:24 +0200 (CEST) To: "'Stanislav Malyshev'" , "'PHP Internals'" References: <3a5408bc-b71d-920c-45e4-b9be02350b6c@gmail.com> In-Reply-To: <3a5408bc-b71d-920c-45e4-b9be02350b6c@gmail.com> Date: Mon, 24 Oct 2016 16:56:21 +0200 Message-ID: <01a901d22e06$ca4e3450$5eea9cf0$@belski.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIw/dPx2uTzgX7O3dl7/zFSJ2INJp/6B+ww Content-Language: en-us Subject: RE: [PHP-DEV] Security issue handling From: anatol.php@belski.net ("Anatol Belski") Hi Stas, Thanks for bringing this up. > -----Original Message----- > From: Stanislav Malyshev [mailto:smalyshev@gmail.com] > Sent: Monday, October 24, 2016 7:16 AM > To: PHP Internals > Subject: [PHP-DEV] Security issue handling >=20 > Hi! >=20 > I'd like to discuss an issue about security bugs handling. >=20 > We have a security repo which I and others check into bugs from time = to > time. The idea is for these to be reviewed by people having access = there > before we merge them, and then merge after the release. >=20 > This, however, is not happening at all. The patches, as far as I know, > are not reviewed at all, and merging a bunch of patches last minute = with > no review is extremely dangerous. I am trying my best with my patches, > but I'm only human, and I feel increasingly uncomfortable having so = many > unreviewed patches in the release. >=20 > So, how we can fix it? >=20 > a. We could merge some of the patches on RC stage, even though that > might expose some issues. Related to my response in another bug, we could indeed make definitions = and partially merge the low severity patches already into RC. Also, with = the high severity patches - it'd make sense to define some time range = where new patches are acceptable for the next 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 = serucity repo, ported and tested 5 days before tag. Fe Thursday/Friday = in week before final, it is required to have all the security patches = prepared. Until some urgent patch were already disclosed, so it would = have to be applied right at the last second, having more buffer will = lead to more stability.=20 > b. We could somehow improve review mechanism beyond security repo we > have now - ideas? IMHO it were the best option, indeed building a security response team. = We need more people on this. 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. > c. Get some specific people to volunteer to review patches in security > repo regularly - how? Any takers? >=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. 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. On my side, I'm already intended to go deeper into the security patches = at least a week before finals. Until it's defined otherwise, I'll be at = least preparing the 5.6->7.0 ports and testing so we have some more time = to discuss and more chance to avoid tag delays. I might have time to = participate on security tickets, when 7.0 goes into security only mode, = but unfortunately can't afford full security team participation ATM. Regards Anatol