Re: [PHP-DEV] Low Hanging Fruit
On 11/1/2016 11:08 PM, Michael Morris wrote: What are some outstanding bugs that should be relatively easy to fix that no one has gotten around to? Low hanging fruit as it were for beginning devs. Bug #72333 should be relatively easy and is most likely still a valid bug under the PHP 7 series. I've been busy with other things but, while researching the issue, I came up with a one-liner that has a pretty good chance of fixing the problem and there is even a consistent test case to demonstrate the problem. Bugfixes rarely get much more silver platter than that. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Introduction for wilkesreid
2016-11-02 21:04 GMT+01:00 Samuel Reid : > I would simply like the opportunity to vote on RFCs. My name is Samuel Reid, > and I’m a PHP developer for Bureau Gravity (http://www.bureaugravity.com). > It is a privilege to be able to vote on RFCs, see http://php.net/get-involved.php for how you can contribute to PHP. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Introduction for wilkesreid
I would simply like the opportunity to vote on RFCs. My name is Samuel Reid, and I’m a PHP developer for Bureau Gravity (http://www.bureaugravity.com).
Re: [PHP-DEV] bug classification discussion
Hi, On Mon, Oct 24, 2016 at 6:23 AM, Stanislav Malyshev 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. Cheers
[PHP-DEV] UGLY Benchmark Results for PHP Master 2016-11-02
Results for project PHP master, build date 2016-11-02 06:24:53+02:00 commit: c71ab72 previous commit:fec1218 revision date: 2016-11-01 22:58:59+03:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB mem:128 GB os: CentOS 7.1 kernel: Linux 3.10.0-229.4.2.el7.x86_64 Baseline results were generated using release php-7.0.0, with hash 60fffd2 from 2015-12-01 04:16:47+00:00 --- benchmark relative change since change since current rev run std_dev* last run baseline with PGO --- :-| Wordpress 4.2.2 cgi -T1 0.27% 0.37% 0.67% 6.87% :-| Drupal 7.36 cgi -T1 0.16% 0.41% 0.22% 4.06% :-| MediaWiki 1.23.9 cgi -T5000 0.11% 0.35% 0.99% 3.56% :-) bench.php cgi -T100 0.02% 2.09% 33.20% -0.24% :-) micro_bench.php cgi -T10 0.04% 3.78% 14.71% -1.65% :-( mandelbrot.php cgi -T100 0.01% -1.08% 30.81% -7.94% --- * Relative Standard Deviation (Standard Deviation/Average) If this is not displayed properly please visit our results page here: http://languagesperformance.intel.com/ugly-benchmark-results-for-php-master-2016-11-02/ Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in fetches/second while all others are measured in seconds. More details on measurements methodology at: https://01.org/lp/documentation/php-environment-setup. Subject Label Legend: Attributes are determined based on the performance evolution of the workloads compared to the previous measurement iteration. NEUTRAL: performance did not change by more than 1% for any workload GOOD: performance improved by more than 1% for at least one workload and there is no regression greater than 1% BAD: performance dropped by more than 1% for at least one workload and there is no improvement greater than 1% UGLY: performance improved by more than 1% for at least one workload and also dropped by more than 1% for at least one workload Our lab does a nightly source pull and build of the PHP project and measures performance changes against the previous stable version and the previous nightly measurement. This is provided as a service to the community so that quality issues with current hardware can be identified quickly. Intel technologies' features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PDO ODBC #42765 uninitialized length bug patch
Would a developer be able look at the patch in this bug: https://bugs.php.net/bug.php?id=42765 And let me know what else needs to happen to get this committed? This is pretty much required to make the module work correctly with most SQL server databases via ODBC. I'm hitting this on multiple OSes and they are telling to get it committed upstream instead of patching the local package. -- Anish -- Anish -- Anish
Re: [PHP-DEV] Security issue handling
Morning, Stas, consider Leigh vouched for, please add him to sec lists and private bugs. Cheers Joe On Wed, Nov 2, 2016 at 11:14 AM, Leigh wrote: > On 24 October 2016 at 06:16, Stanislav Malyshev > wrote: > > Hi! > > > > I'd like to discuss an issue about security bugs handling. > > > > 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. > > > > 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. > > > > So, how we can fix it? > > > > a. We could merge some of the patches on RC stage, even though that > > might expose some issues. > > b. We could somehow improve review mechanism beyond security repo we > > have now - ideas? > > c. Get some specific people to volunteer to review patches in security > > repo regularly - how? Any takers? > > > > Would like to hear thoughts on this one. > > -- > > Stas Malyshev > > smalys...@gmail.com > > Hey Stas, > > If it's extra volunteers that you need, I would also be happy to help > out where I can, investigating reported issues, writing and reviewing > patches. > > * I have a provable interest in security > * I've submitted security issues (to PHP and other projects) in the past > * I have worked on security features for the PHP runtime in the past > * I already have karma \o/ > > Regards, > > Leigh. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Security issue handling
On 24 October 2016 at 06:16, Stanislav Malyshev wrote: > Hi! > > I'd like to discuss an issue about security bugs handling. > > 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. > > 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. > > So, how we can fix it? > > a. We could merge some of the patches on RC stage, even though that > might expose some issues. > b. We could somehow improve review mechanism beyond security repo we > have now - ideas? > c. Get some specific people to volunteer to review patches in security > repo regularly - how? Any takers? > > Would like to hear thoughts on this one. > -- > Stas Malyshev > smalys...@gmail.com Hey Stas, If it's extra volunteers that you need, I would also be happy to help out where I can, investigating reported issues, writing and reviewing patches. * I have a provable interest in security * I've submitted security issues (to PHP and other projects) in the past * I have worked on security features for the PHP runtime in the past * I already have karma \o/ Regards, Leigh. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php