Hi, On Oct 28, 2016 10:33 PM, "Ferenc Kovacs" <tyr...@gmail.com> wrote: > > On Fri, Oct 28, 2016 at 11:18 AM, Remi Collet <r...@fedoraproject.org> > wrote: > > > Le 24/10/2016 à 07:23, Stanislav Malyshev a écrit : > > > 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, > > > > My main concern is not to know if we treat this bugs as security or not. > > > > It is mainly about "classification", and I think "low" risk bugs should > > be fixed using the normal bug process (going in a RC versions) rather > > than a specific process (fixed only at GA time), which should be > > reserved for higher risk bugs. > > > > > > Remi > > > > > > > I agree with Remi, these should be fixed via the normal development process > so we can catch any issues during the RC. > These are basically the same issue, they can be exploited the same way > (which I agree that has a low Exploitability) so we don't really gain much > by keeping them until the final release but we risk a lot from skipping the > general QA process.
Thanks Stas for bringing that up. It is indeed a case by case decision, however I fully agree with Remi and Tyrael here, for the cases described by Stas initial post (or similar). It is extremely hard to do it in a short time during final phases, let alone the risk to create more damages by applying a bad fix. About marking them as low security bugs or not. I have no strong opinion. Maybe we could define what is a production environment and then define bugs affecting this environment as security issues. Cheers Pierre
