Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96802 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97693 invoked from network); 9 Nov 2016 23:49:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Nov 2016 23:49:38 -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:50610] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 39/3C-15787-F06B3285 for ; Wed, 09 Nov 2016 18:49:35 -0500 Received: by h1123647.serverkompetenz.net (Postfix, from userid 1006) id A1B27782D68; Thu, 10 Nov 2016 00:49:32 +0100 (CET) Received: from w530phpdev (p54A76B81.dip0.t-ipconnect.de [84.167.107.129]) (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 601C1782D66; Thu, 10 Nov 2016 00:49:30 +0100 (CET) To: "'Jakub Zelenka'" , "'Stanislav Malyshev'" Cc: "'PHP Internals'" , "'Remi Collet'" References: <1ae4bea0-d62b-fd61-f6b6-55762e97df6e@gmail.com> In-Reply-To: Date: Thu, 10 Nov 2016 00:49:27 +0100 Message-ID: <025e01d23ae3$ea0578a0$be1069e0$@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: AQGoROuhyhG09wpdFsCUAeRJuSqPfQGXZCLioRh79WA= Content-Language: en-us Subject: RE: [PHP-DEV] bug classification discussion From: anatol.php@belski.net ("Anatol Belski") Hi, > -----Original Message----- > From: jakub.php@gmail.com [mailto:jakub.php@gmail.com] On Behalf Of = Jakub > Zelenka > Sent: Wednesday, November 2, 2016 8:36 PM > To: Stanislav Malyshev > Cc: PHP Internals ; Remi Collet > > Subject: Re: [PHP-DEV] bug classification discussion >=20 > Hi, >=20 > On Mon, Oct 24, 2016 at 6:23 AM, Stanislav Malyshev = > wrote: >=20 > > Hi! > > > > We have had a bunch of bugs recently which are essentially one and = the > > same issue: PHP 5.6 allows only int-sized strings, but many = functions > > don't check the size of the string they produce. This can lead to = int > > overflows inside php and also can break other libraries that also > > assume string sizes are ints and this can cause all kinds of = weirdness. > > However, these bugs are very unlikely to manifest in production > > setting for one simple reason - they require PHP to run with no = memory > > limit, and I haven't seen many setups that run with no memory limit. > > I'm not going to go into specifics here, since some of the issues = are > > still not fixed, but you can talk to me privately if you need = examples > > or browse changelogs of later 5.6 releases. > > > > A twin brother of this is in 7.0 where there are just integer > > overflows in string size calculations. Usually that requires huge > > strings as inputs, so also requires running with no memory limit. > > > > These bugs are now treated as security issues, due to the fact that = in > > theory somebody might be running with no memory limit and get huge > > string as an input from user. However, it was questioned that we > > indeed should treat them so, due to the fact that encountering them = in > > production is unlikely, and due to the fact that they require = patching > > in many places, and merging those fixes out-of-band creates > > significant potential for bugs. > > > > > I would probably treat them as a low severity issues. It means just = not disclose > them until they are fixed and let RM decide if they want to pull them = to the > branches for security fixes only. The thing is that it might take time = till they are > fixed so better not to keep them publicly visible. >=20 It looks, like there's the consensus on https://wiki.php.net/security in = its current form, so probably no additional measures like voting are = needed. Given that, I would suggest these classifications to officially = become effective, so we start to apply them already for the subsequent = releases. Are there any objections? Thanks Anatol