Re: [PHP-DEV] Introduction for wilkesreid

[Kalle Sommer Nielsen]

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

[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).

Re: [PHP-DEV] bug classification discussion

[Jakub Zelenka]

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

[lp_benchmark_robot]

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

[Anish Mistry]

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

[Joe Watkins]

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

[Leigh]

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] Low Hanging Fruit

[Yasuo Ohgaki]

Hi Michael,

On Wed, Nov 2, 2016 at 3: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.

Easy is depends on what you know.
There are many. You can find them easily
https://bugs.php.net/

Just send pull request from github. We don't have much resource so
PR may take long time until merge.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Low Hanging Fruit

[Michael Morris]

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.