Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions

[Aaron Piotrowski]

Hi Dan,

> On Jun 29, 2016, at 3:41 PM, Dan Ackroyd  wrote:
> 
> For the record, I'm beginning to think the RFC process should probably
> be slightly more orchestrated, and RFCs should have a "pre-vote"
> announcement at least one week before the vote actually opens, when
> the RFC author thinks the discussion of the RFC is complete.
> 
> This point would be the time for the implementations full impact on
> the PHP engine to be analyzed, and also when the final voting choice
> can be discussed/challenged before the voting is actually open.
> 

Sorry if this RFC was a little rushed. I originally hoped to make these changes 
for 7, then the original PR got pushed off to 7.1 and forgotten about until it 
was almost too late even for 7.1.

I agree that a pre-vote phase could be useful, as it may help bring more 
attention to an RFC before voting actually opens. There seems to be a pattern 
of issues with RFCs not being discussed until voting has begun. The pre-vote 
phase could replace one week of the discussion period, so an RFC would still 
only need a minimum of two weeks between announcement and voting.

Cheers!

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

[PHP-DEV] About PHP 7.1.0 Feature Freeze

[Davey Shafik]

Hi internals,

Last week we pushed out 7.1.0alpha2, and are progressing nicely toward
7.1.0.

However, due to a couple of open RFCs and discussions, it has been decided
that we will be releasing alpha3 on July 7th instead of beta1. This will
push beta1 (and all subsequent builds) back two weeks.

FEATURE FREEZE and BRANCHING will happen on July 19th, 2 days prior to the
7.1.0beta1 release on July 21st.

This means if you do not currently have an RFC in discussion, and heading
to voting in the next week or so, you will need to start targetting 7.2.
Any exceptions to this will be made by the RM team on a case-by-case basis
as per-usual.

Thanks,

- Davey Shafik & Joe Watkins

Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions

[Pierre Joye]

On Jun 30, 2016 3:41 AM, "Dan Ackroyd"  wrote:
>
> On 28 June 2016 at 03:36, Pierre Joye  wrote:
> >
> > I like the idea.
> >
> > It should be 2/3 tho'.
>
> Why?
>
> It's not a language change, so doesn't seem to meet the criteria for
> needing a 2/3 pass rate.

It is changing the core like ext/standard and other core functions.

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

[Yasuo Ohgaki]

Hi Stas,

On Wed, Jun 29, 2016 at 9:09 AM, Stanislav Malyshev  wrote:
>
>> Concern has been discussed is risk of broken PRNG and predictable
>> session ID. We may insist any platform must have reliable PRNG, but it
>> would be good idea to have least mitigation. Reading extra bytes
>> should be good enough for this purpose.
>
> I still see no reason to change it stated in the RFC except performance
> (which is irrelevant in all contexts I know of). It states the change
> but omits the reason why this change is necessary. Could you please add
> that part?

Sure.
The main purpose is clean up.

The reason we have messy session ID creation code for hashing and
generating random bytes is we didn't have reliable cross platform PRNG
code. We have it now, so no reason to keep complex/redundant/inefficient code.

I'll add this.

Thank you.

--
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] Throw Error in Extensions

[Dan Ackroyd]

On 28 June 2016 at 03:36, Pierre Joye  wrote:
>
> I like the idea.
>
> It should be 2/3 tho'.

Why?

It's not a language change, so doesn't seem to meet the criteria for
needing a 2/3 pass rate.

For the record, I'm beginning to think the RFC process should probably
be slightly more orchestrated, and RFCs should have a "pre-vote"
announcement at least one week before the vote actually opens, when
the RFC author thinks the discussion of the RFC is complete.

This point would be the time for the implementations full impact on
the PHP engine to be analyzed, and also when the final voting choice
can be discussed/challenged before the voting is actually open.

cheers
Dan

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

Re: [PHP-DEV] New escaped output operator

[Михаил Востриков]

Hello. I've created an article on russian technical site habrahabr.ru.
https://habrahabr.ru/post/304162/

There is a poll about introducing of such operator. About 60% from those
people who have projects without template engine are "for" this operator.
And even a half of those who don't also think that such operator can be
useful.

I think you can use Google Translate to read it, common sense and code
examples should be understandable.
https://translate.google.com/translate?sl=en=ru=y=_t=ru=UTF-8=https%3A%2F%2Fhabrahabr.ru%2Fpost%2F304162%2F==url

Current results:


How often do you work with the projects with template rendering on PHP
where template engines are not used?
35% (163)  Always
22% (104)  Quite often
18% (86)   Quite rare
25% (117)  Almost never

Voted 470 people. Abstained 116 people.


How do you think, such an operator would be useful?
56% (264)  Yes
44% (207)  No

Voted 471 people. Abstained 121 people.


I don't use PHP teplate rendering ...
51% (147)  and I think that such an operator is not needed
49% (139)  but I think that such an operator will come in handy

Voted 286 people. Abstained 247 people.


Screenshot in Russian:
https://habrastorage.org/files/675/9ac/883/6759ac8834044ef0b5a09163c791f376.png


60% are "for" this operator, projects of others 40% will not be affected.
I think this is a good reason to create an RFC and discuss it on more
global level.



2016-06-21 9:51 GMT+05:00 Михаил Востриков :

> > So, not needed in all 3 cases then...
> So, we can still use 
>
> >> Imagine that urlencode does not encode quotes - what function should we
> >> call for its result?
> > Ideally, an escape filter that performs both functions; if the aim is to
> make things easier
> No. The second function really depends on context, but HTML context is
> always present. The aim is to create a shortcut for HTML escaping, decrease
> copy-paste, and increase security.
>
>
> > I shouldn't need to think about the need to nest two escape functions.
> > the claim of "secure by default" doesn't really stand up.
> This is about super-universal-operator. I did not suggest "secure by
> default". As Thomas said, this is just an alias, not more, not less.
>
>
> > $('[data-thing-id="]').on('click',
> function(){doThing(''});
> > I'm pretty sure the tempting syntax is actively harmful in that
> situation...
> You should not call htmlspecialchars inside script tags, even without  operator. Because this is not an HTML context.
>
>
> > HackLang's XHP is another - rather than thinking about escaping as an
> action
> > If the compiler could look at my previous example and recognise the
> attribute, URL, script, and text contexts itself
> This is very complex solution, and it can make some issues with
> performance. Also, as I understand, it just calls htmlspecialchars.
> https://github.com/facebook/xhp-lib/blob/master/src/core/XHP.php#L68
> https://github.com/facebook/xhp-lib/blob/master/src/html/Element.php#L122
>
>
> > what is the correct escape method for an attribute named "data-my-action"
> It should be HTML-encoded, because it is HTML markup.
>
>
> > And that is exactly the problem. Inventing operators to alias one
> > invocation of one function with one specific set of parameters is not a
> > good idea, unless there is a *VERY* good reason to do it.
> The call of htmlspecialchars is very frequent case, specific set of
> parameters (HTML context) is always present. Is it a very good reason?
>
>
> > And the case for this specific piece of code to deserve its own operator
> is rather weak.
> Why do you think so, why is it weak?) As I showed, HTML context is always
> present, even if we write inline javascript in 'onclick' attribute.
> This is not another context, there are 2 contexts together, and there is
> no needs to determine it inside compiler - one context is always here.
> So, it deserve its own operator.
>
>
>
> Let's summarize.
>
> We must not call htmlspecialchars() in the following cases:
>
> Inside 

Re: [PHP-DEV] [RFC] RNG fixes

[Pierre Joye]

On Jun 29, 2016 10:03 PM, "Leigh"  wrote:
>
> I think I've caught up on everything discussed now.
>
> One thing I would like to point out, when people have searched for
> "legitimate uses" of mt_rand(), you should have been looking for
> legitimate uses of mt_srand() - this is the functionality that will be
> broken.
>
> On 16 June 2016 at 03:21, Pierre Joye  wrote:
> > There are ways to achieve what you want in a nice way while not breaking
> > things. Let consider them.
> >
> > Cheers,
> > Pierre
>
> So what would you suggest? mt_rand_mode() with constants for correct
> and legacy? (defaulting to correct, and a single fcall for users to
> get the old behaviour back)

Yes that would make it. Even if i would prefer the other way for at least
one version.

Re: [PHP-DEV] [RFC] RNG fixes

[Leigh]

I think I've caught up on everything discussed now.

One thing I would like to point out, when people have searched for
"legitimate uses" of mt_rand(), you should have been looking for
legitimate uses of mt_srand() - this is the functionality that will be
broken.

On 16 June 2016 at 03:21, Pierre Joye  wrote:
> There are ways to achieve what you want in a nice way while not breaking
> things. Let consider them.
>
> Cheers,
> Pierre

So what would you suggest? mt_rand_mode() with constants for correct
and legacy? (defaulting to correct, and a single fcall for users to
get the old behaviour back)

-- 
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-06-29

[lp_benchmark_robot]

Results for project PHP master, build date 2016-06-29 06:30:02+03:00
commit: 0a4f89b
previous commit:ae8cf3cb
revision date:  2016-06-28 20:39:31+01: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.25%  0.56%  
  7.67%
:-|   Drupal 7.36 cgi -T1  0.14%  0.51% -0.17%  
  4.79%
:-|   MediaWiki 1.23.9 cgi -T5000  0.11%  0.16%  1.31%  
  3.84%
:-|   bench.php cgi -T100  0.02% -0.93% 26.90%  
 -6.96%
:-)  micro_bench.php cgi -T10  0.00%  1.34%  5.34%  
  2.39%
:-)  mandelbrot.php cgi -T100  0.02%  1.75% 31.58%  
  1.86%
---

* 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-06-29/

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] Re: Send files in CURL from string

[Alexander Moskalev]

Last try to highlight this thread


-- 
With regards, Alexander Moskalev
ir...@irker.net
ir...@php.net
a.moska...@corp.badoo.com

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

[Pierre Joye]

Hi :)

On Wed, Jun 29, 2016 at 7:09 AM, Stanislav Malyshev  wrote:
> Hi!
>
>> Concern has been discussed is risk of broken PRNG and predictable
>> session ID. We may insist any platform must have reliable PRNG, but it
>> would be good idea to have least mitigation. Reading extra bytes
>> should be good enough for this purpose.
>
> I still see no reason to change it stated in the RFC except performance
> (which is irrelevant in all contexts I know of). It states the change
> but omits the reason why this change is necessary. Could you please add
> that part?

Same here.

I have to ask again what prevents you to write your own custom session
module and do everything you consider as safe in there. But this kind
of changes sounds not very helpful and not really done for valid
reasons (for that one). I fully understand the goal to secure (and
this is a very open definition) session manage for php but this cannot
be done in step by step basis.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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