Hi, > -----Original Message----- > From: jakub....@gmail.com [mailto:jakub....@gmail.com] On Behalf Of Jakub > Zelenka > Sent: Wednesday, November 2, 2016 8:36 PM > To: Stanislav Malyshev <smalys...@gmail.com> > Cc: PHP Internals <internals@lists.php.net>; Remi Collet > <r...@fedoraproject.org> > Subject: Re: [PHP-DEV] bug classification discussion > > Hi, > > On Mon, Oct 24, 2016 at 6:23 AM, Stanislav Malyshev <smalys...@gmail.com> > wrote: > > > 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. > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
