Re: [PHP-DEV] [RFC][VOTE] Session ID without hashing - Reopened

[Davey Shafik]

My suggestion:

Re-start the vote, three options:

Yes, new defaults (BC Break), Yes, old defaults (no BC break), No

OR:

add a second vote to the page, with:

Use new defaults (BC Break), Use Old Defaults (No BC Break)

On Sun, Jul 24, 2016 at 6:52 PM, Yasuo Ohgaki  wrote:

> Hi all,
>
> I would like to ask the default session ID string preference.
>
> Details of guessing an active session ID is described in previous mail.
> Please refer it for details.
>
> On Sun, Jul 24, 2016 at 4:57 PM, Yasuo Ohgaki  wrote:
> > I don't mind pausing vote to have consensus on how many bits for
> > session ID string is preferred.
>
> Current default is 128 bits with 32 chars. (Hex string which has 4
> bits per char)
> Pros: Compatible with current default.
> Cons: Weaker than proposed default
>
> Proposed default is 240 bits with 48 chars. (Special form which has 5
> bits per char)
> Pros: Stronger than current default.
> Cons: Incompatible with current default.
>
> 128 bits would be strong enough with CSPRNG, while 240 bits would be
> preferred as precaution.
> Which default would you prefer?
>
> I would like to restart vote based on the result.
>
> Thank you!
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] Bundled SQLlite3

[Davey Shafik]

I'd like to see an updated SQLite in 7.1, this is part of shoring up the
stability of the release IMO.

- Davey

On Sun, Jul 24, 2016 at 11:57 PM, Anatol Belski 
wrote:

> Hi Christoph,
>
> > -Original Message-
> > From: Christoph Becker [mailto:cmbecke...@gmx.de]
> > Sent: Monday, July 25, 2016 12:49 AM
> > To: internals@lists.php.net
> > Subject: [PHP-DEV] Bundled SQLlite3
> >
> > Hi!
> >
> > What's our stance on updating the bundled SQLite3?
> >
> > Currently the PHP-5.6 and 7.0 branch have 3.8.10.2, while the PHP-7.1 and
> > master branch have 3.9.2 (sqlite3.h) respectively 3.13.0 (sqlite3.c).
> The latter
> > would have certainly to be fixed to be consistent, but I have some doubts
> > regarding sticking with old SQLite3 versions for supported PHP
> versions.  After all,
> > all minor versions at least as of SQLite 3.9.0 are "regularly scheduled
> > maintenance releases"[1], and it appears that no bug-fixes will be
> published for
> > non-current minor versions.
> >
> Normally it is ok to upgrade the bundled libsqlite. When done carefully,
> even in the stable branch. Fe from the news you've linked - "Yikes! The
> 3.12.0 and 3.12.1 releases contain a backwards compatibility bug!" :) But
> similar situations already happened before. However not upgrading it at all
> for 3 years is also not good, so fine with upgrading it from time to time.
> A respective RM should be better asked for approval.
>
> Regards
>
> Anatol
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

[PHP-DEV] stat cache / still needed these days?

[Philip Hofstetter]

Hi,

I have just reported #72666 (touch() works differently on plain paths
and file:// paths with regards to cleaning the stat cache) and I would
gladly provide a PR with a fix and unit tests. However, before I start
working on this (well - it would be an easy fix), I would like to
question whether the stat cache is a good idea and whether it's still
(or ever was) needed these days.

File systems right now are really good at quickly providing the
information: On MacOS I measure only 10% loss in performance when
doing nothing but calling stat() and clearstatcache() compared to just
calling stat(). Over NFS on Linux, it's 20%.

Additionally, I wonder what the stat cache is actually helpful for -
as far as I understand it, this only helps if you repeatedly call
stat() (or a related function) on the same file within the same
request which probably isn't very common application behaviour to
begin with.

As such, before I fix touch() to call php_clear_stat_cache(), maybe
it's worth reconsidering the whole thing and removing it from PHP
itself at least for later versions, though I guess there I would be in
firm RFC territory which I'd be willing to write if I had RFC writing
credentials.

What do you think?

Philip

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

Re: [PHP-DEV] Bundled SQLlite3

[Christoph Becker]

On 25.07.2016 at 09:11, Davey Shafik wrote:

> I'd like to see an updated SQLite in 7.1, this is part of shoring up the
> stability of the release IMO.

Thanks, Anatol and Davey for the fast reply.

After having a closer look at the release news, it seems that there have
been no major bugs in 3.8.10.2, and that release is not so old
(2015-05-20), so I leave 5.6 and 7.0 as is.

7.1 and master should, however, be fixed (i.e. update of sqlite3.h and
sqlite3ext.h to 3.13.0).  Done with
.

I'll try to keep an eye on SQLite3 wrt. new releases and possibly
necessary updates in PHP.

> On Sun, Jul 24, 2016 at 11:57 PM, Anatol Belski 
> wrote:
> 
>> Hi Christoph,
>>
>>> -Original Message-
>>> From: Christoph Becker [mailto:cmbecke...@gmx.de]
>>> Sent: Monday, July 25, 2016 12:49 AM
>>> To: internals@lists.php.net
>>> Subject: [PHP-DEV] Bundled SQLlite3
>>>
>>> Hi!
>>>
>>> What's our stance on updating the bundled SQLite3?
>>>
>>> Currently the PHP-5.6 and 7.0 branch have 3.8.10.2, while the PHP-7.1 and
>>> master branch have 3.9.2 (sqlite3.h) respectively 3.13.0 (sqlite3.c).
>> The latter
>>> would have certainly to be fixed to be consistent, but I have some doubts
>>> regarding sticking with old SQLite3 versions for supported PHP
>> versions.  After all,
>>> all minor versions at least as of SQLite 3.9.0 are "regularly scheduled
>>> maintenance releases"[1], and it appears that no bug-fixes will be
>> published for
>>> non-current minor versions.
>>>
>> Normally it is ok to upgrade the bundled libsqlite. When done carefully,
>> even in the stable branch. Fe from the news you've linked - "Yikes! The
>> 3.12.0 and 3.12.1 releases contain a backwards compatibility bug!" :) But
>> similar situations already happened before. However not upgrading it at all
>> for 3 years is also not good, so fine with upgrading it from time to time.
>> A respective RM should be better asked for approval.
>>
>> Regards
>>
>> Anatol

-- 
Christoph M. Becker

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

Re: [PHP-DEV] [RFC][VOTE] Session ID without hashing - Reopened

[Yasuo Ohgaki]

Hi Davey,

On Mon, Jul 25, 2016 at 4:09 PM, Davey Shafik  wrote:
> My suggestion:
>
> Re-start the vote, three options:
>
> Yes, new defaults (BC Break), Yes, old defaults (no BC break), No
>
> OR:
>
> add a second vote to the page, with:
>
> Use new defaults (BC Break), Use Old Defaults (No BC Break)

Sounds good to me.
I'll use 2nd option and restart.

Thanks

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

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

Re: [PHP-DEV] [RFC][VOTE] Session ID without hashing - Reopened

[Yasuo Ohgaki]

Hi Davey,

On Mon, Jul 25, 2016 at 5:46 PM, Yasuo Ohgaki  wrote:
>
> On Mon, Jul 25, 2016 at 4:09 PM, Davey Shafik  wrote:
>> My suggestion:
>>
>> Re-start the vote, three options:
>>
>> Yes, new defaults (BC Break), Yes, old defaults (no BC break), No
>>
>> OR:
>>
>> add a second vote to the page, with:
>>
>> Use new defaults (BC Break), Use Old Defaults (No BC Break)
>
> Sounds good to me.
> I'll use 2nd option and restart.

I've updated the RFC.
https://wiki.php.net/rfc/session-id-without-hashing
I've set new vote end date to 2016/08/02 23:59:59.

Could you check if the RFC is OK? If it's OK, I'll create a new thread
for vote notice.

Regards,

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

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

Re: [PHP-DEV] [RFC][VOTE] Session ID without hashing - Reopened

[Davey Shafik]

Looks good to me, go for it :)

Thanks,

- Davey

On Mon, Jul 25, 2016 at 2:14 AM, Yasuo Ohgaki  wrote:

> Hi Davey,
>
> On Mon, Jul 25, 2016 at 5:46 PM, Yasuo Ohgaki  wrote:
> >
> > On Mon, Jul 25, 2016 at 4:09 PM, Davey Shafik  wrote:
> >> My suggestion:
> >>
> >> Re-start the vote, three options:
> >>
> >> Yes, new defaults (BC Break), Yes, old defaults (no BC break), No
> >>
> >> OR:
> >>
> >> add a second vote to the page, with:
> >>
> >> Use new defaults (BC Break), Use Old Defaults (No BC Break)
> >
> > Sounds good to me.
> > I'll use 2nd option and restart.
>
> I've updated the RFC.
> https://wiki.php.net/rfc/session-id-without-hashing
> I've set new vote end date to 2016/08/02 23:59:59.
>
> Could you check if the RFC is OK? If it's OK, I'll create a new thread
> for vote notice.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

RE: [PHP-DEV] stat cache / still needed these days?

[Anatol Belski]

Hi Philip,

> -Original Message-
> From: Philip Hofstetter [mailto:phofstet...@sensational.ch]
> Sent: Monday, July 25, 2016 9:55 AM
> To: PHP internals 
> Subject: [PHP-DEV] stat cache / still needed these days?
> 
> Hi,
> 
> I have just reported #72666 (touch() works differently on plain paths and 
> file://
> paths with regards to cleaning the stat cache) and I would gladly provide a PR
> with a fix and unit tests. However, before I start working on this (well - it 
> would
> be an easy fix), I would like to question whether the stat cache is a good 
> idea
> and whether it's still (or ever was) needed these days.
> 
> File systems right now are really good at quickly providing the
> information: On MacOS I measure only 10% loss in performance when doing
> nothing but calling stat() and clearstatcache() compared to just calling 
> stat().
> Over NFS on Linux, it's 20%.
> 
> Additionally, I wonder what the stat cache is actually helpful for - as far 
> as I
> understand it, this only helps if you repeatedly call
> stat() (or a related function) on the same file within the same request which
> probably isn't very common application behaviour to begin with.
> 
> As such, before I fix touch() to call php_clear_stat_cache(), maybe it's worth
> reconsidering the whole thing and removing it from PHP itself at least for 
> later
> versions, though I guess there I would be in firm RFC territory which I'd be 
> willing
> to write if I had RFC writing credentials.
> 
> What do you think?
> 
Not only single paths fill the cache, but also all the sub-paths. Say for 
/a/b/c/d, all the single sub-parts /a/b/c, /a/b, /a will be cached. So it's not 
just when some file is accessed, but when siblings with the joint parent are 
accessed. This spares a lot of recursive function calls for the path 
resolution. Especially in TS, but also in NTS variant. Even disregarding that, 
I don't really see any functional gain on removing - at the end the path will 
land in some C runtime I/O function as "last authority". From the experience, 
path's barely change within the same request, so the common case profits from 
the path caching.

Regards

Anatol


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

[PHP-DEV] [RFC][VOTE] Session ID without hashing - Vote reopened and restarted

[Yasuo Ohgaki]

Hi all,

Due to defects in the RFC, vote is reopened and restarted.
Followings are changes from 1st vote.

 - Removed session.use_strict_mode change
   (Changed when vote reopened)
 - Added INI default vote options, incompatible and compatible.
   (Changed when 2nd vote is restarted)
 - Extended vote period for 2 days.

These who are voted already have to **VOTE AGAIN**.
Sorry for the inconvenience and confusion!



Currently session module uses obsolete MD5 for session ID. With
CSPRNG, hashing is redundant and needless. It adds hash module
dependency and inefficient.

This proposal cleans up session code by removing hash.

https://wiki.php.net/rfc/session-id-without-hashing

I set vote requires 2/3 support.
Please describe the reason why when you against this RFC. Reasons are
important for improvements!

Vote ends 2016/08/02 23:59:59 UTC.

Thank you for voting!

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

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

Re: [PHP-DEV] [RFC][VOTE] Session ID without hashing - Reopened

[Yasuo Ohgaki]

Hi Davey,

On Mon, Jul 25, 2016 at 6:35 PM, Davey Shafik  wrote:
> Looks good to me, go for it :)

Done.
Thank you for helping!

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

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

[PHP-DEV] GOOD Benchmark Results for PHP Master 2016-07-25

[lp_benchmark_robot]

Results for project PHP master, build date 2016-07-25 06:29:10+03:00
commit: abb228e
previous commit:49ddd03
revision date:  2016-07-25 02:04:29+02: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.14%  0.64%  0.13%  
  8.11%
:-)   Drupal 7.36 cgi -T1  0.17%  1.05% -1.42%  
  6.22%
:-|   MediaWiki 1.23.9 cgi -T5000  0.09% -0.35% -0.35%  
  4.16%
:-)   bench.php cgi -T100  0.01%  2.12% 32.42%  
 -0.47%
:-)  micro_bench.php cgi -T10  0.07%  3.72% 14.44%  
  0.01%
:-|  mandelbrot.php cgi -T100  0.30% -0.95% 31.07%  
  5.45%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/good-benchmark-results-for-php-master-2016-07-25/

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

Re: [PHP-DEV] Pipe Operator v2

[Björn Larsson]

Den 2016-07-22 kl. 17:05, skrev David Rodrigues:


It's possible to use the tilde ~ easyly on keyboards?
For on BR/ABNT2 is easy. So maybe use ~> as operator could be fine,
instead of the triangle |>, and linear sounds good too, like:
$string~>escape($$)~>dump($$);

It's used currently on PHP for a bitwise operation (not), so I think
that the usage are not a problem in general.
Too will not have a conflict, because ~> no make any sense to PHP today.

There was an RFC proposing that operator for short closures, see:
- https://wiki.php.net/rfc/short_closures

Recall that the operator was a bit controversial due to
e.g. japanese keyboard. Personally I liked the proposal
and I think the "pipe" sign fit well into an pipe operator:)

Regards //Björn Larsson

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

RE: [PHP-DEV] Bundled SQLlite3

[Anatol Belski]

> -Original Message-
> From: Christoph Becker [mailto:cmbecke...@gmx.de]
> Sent: Monday, July 25, 2016 10:30 AM
> To: Davey Shafik ; Anatol Belski 
> Cc: internals@lists.php.net; Ferenc Kovacs 
> Subject: Re: [PHP-DEV] Bundled SQLlite3
> 
> On 25.07.2016 at 09:11, Davey Shafik wrote:
> 
> > I'd like to see an updated SQLite in 7.1, this is part of shoring up
> > the stability of the release IMO.
> 
> Thanks, Anatol and Davey for the fast reply.
> 
> After having a closer look at the release news, it seems that there have been 
> no
> major bugs in 3.8.10.2, and that release is not so old (2015-05-20), so I 
> leave 5.6
> and 7.0 as is.
> 
For 7.0 it should be fine as well, I guess. I just meant it's usually enough to 
ask the RM of the lowest branch, as then it'll have to be merged up anyway.

Thanks

Anatol

> 7.1 and master should, however, be fixed (i.e. update of sqlite3.h and
> sqlite3ext.h to 3.13.0).  Done with  src/commit/ee07e23>.
> 
> I'll try to keep an eye on SQLite3 wrt. new releases and possibly necessary
> updates in PHP.
> 
> > On Sun, Jul 24, 2016 at 11:57 PM, Anatol Belski
> > 
> > wrote:
> >
> >> Hi Christoph,
> >>
> >>> -Original Message-
> >>> From: Christoph Becker [mailto:cmbecke...@gmx.de]
> >>> Sent: Monday, July 25, 2016 12:49 AM
> >>> To: internals@lists.php.net
> >>> Subject: [PHP-DEV] Bundled SQLlite3
> >>>
> >>> Hi!
> >>>
> >>> What's our stance on updating the bundled SQLite3?
> >>>
> >>> Currently the PHP-5.6 and 7.0 branch have 3.8.10.2, while the
> >>> PHP-7.1 and master branch have 3.9.2 (sqlite3.h) respectively 3.13.0
> (sqlite3.c).
> >> The latter
> >>> would have certainly to be fixed to be consistent, but I have some
> >>> doubts regarding sticking with old SQLite3 versions for supported
> >>> PHP
> >> versions.  After all,
> >>> all minor versions at least as of SQLite 3.9.0 are "regularly
> >>> scheduled maintenance releases"[1], and it appears that no bug-fixes
> >>> will be
> >> published for
> >>> non-current minor versions.
> >>>
> >> Normally it is ok to upgrade the bundled libsqlite. When done
> >> carefully, even in the stable branch. Fe from the news you've linked
> >> - "Yikes! The
> >> 3.12.0 and 3.12.1 releases contain a backwards compatibility bug!" :)
> >> But similar situations already happened before. However not upgrading
> >> it at all for 3 years is also not good, so fine with upgrading it from 
> >> time to
> time.
> >> A respective RM should be better asked for approval.
> >>
> >> Regards
> >>
> >> Anatol
> 
> --
> Christoph M. Becker
> 
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
> http://www.php.net/unsub.php



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

[PHP-DEV] Request for rfc karma

[David Walker]

Hi All,

I'm desiring to propose my second RFC (thanks bishop for the intro)
regarding PR2031  . Seems there
has been a couple PR's attempting to raise a notice when accessing
non-array-like containers; and I'd like to propose something to attempt to
resolve the open bugs/PR's.

wiki user: bp1222

Thanks
--
Dave