[PHP-DEV] [PHP DEV] Bugs, BC, Strict Mode??

[Michael Morris]

I've seen a couple bug fixes come up that create BC breaks for the code
reliant on the broken behavior.

JavaScript has a opt in strict mode for this. Perhaps PHP could do the
same. An opt in mode with the declare directive that turns on bug fixes
that are BC problems.

One recent example, the behavior of parse_url.

The ternary operator being backwards (right to left instead of left to
right as in all other languages) is another.

This approach lets some PHP 8 code be developed early by making troublesome
bug fixes available early.

The drawback is code bloat - both implementations would be in the code at
the same time. Also, core functions would need to check if the calling code
wants the normal or strict version of the function.

Or maybe namespaces and the use (use Strict; ) could handle this.

Re: [PHP-DEV] Bug fix and RFC/Merge rule

[Stanislav Malyshev]

Hi!

> I don't understand the reasoning why it requires RFC nor Merge
> approval. As we all know, there are many bug fixes without RFC nor
> discussion.

If the fix is uncontroversial (everybody agrees), no RFC/approval is
needed, since there already is approval, since nobody objects, which is
by definition approval. However, if somebody does object, then we need
to go through the process of determining consensus, namely, the RFC
vote, or relying on the judgment of the person we selected to do this -
namely, the RM.

> The patch fixes "uniqid() is not unique enough" bug.

I'm still not sure why this is even a bug, but I was pretty silent since
I also don't mind changing it that much.

> =="Someone explicitly requested RFC/Merge approval, so it should be 
> reverted"==
> 
> IMHO, the patch is very simple patch only fixes problem. Many bug
> fixes include more severe BC issues than the patch, behavior changes
> and raised errors. Yet, no RFC nor discussions.

If somebody objected, there should be discussion and RFC. If nobody
objects, what's there to discuss?

> If someone requested RFC/Merge request for very simple patch, should
> we follow always?

Depends on how simple. Requesting RFC on something like fixing a typo in
error message would be obvious trolling, but if there's a reasonable
objection, then we need to discuss, even if the result of the discussion
is "it's not a problem, merge in". It's not that big of a deal - whole
RFC process can be done in 2-3 weeks if the topic was previously discussed.

> Question is:
>   - What kind of bug fix requires RFC?

One that a) makes user-visible changes, b) serious internal changes that
may substantially influence other developers or c) does not have consensus.

>   - What kind of bug fix requires discussion and approval to merge
> released versions?

One that does not have obvious consensus or introduces BC breaks which
are borderline (i.e. can be allowed in targeted version, in theory).

> After all, my question is "Should we discuss all bugs before commits?"

No, only those that are unobvious changes (fixing obvious crash or bug
or typo does not need discussion) or are controversial.

> "The revert is valid and reasonable?"

If there were objections raised in discussion before merge and they were
not reconciled and merge was still performed, or if there was no
opportunity to raise objections, then yes. I didn't follow the
discussion so I don't know if it's the case here.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: header() removes all header of the same name.

[Yasuo Ohgaki]

Hi Stephen,

On Wed, Oct 19, 2016 at 1:34 PM, Yasuo Ohgaki  wrote:
>> I realise you’re trying to remove WTF cases, but I don’t think removing 
>> advanced capabilities is the way to do that.
>
> Yes. Even framework developer(?) seems to have current behavior.

To be honest, I didn't have idea what's wrong with user provided code
when I have a look at the bug report. I had to experiment a little to
understand what is going on.

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] Re: header() removes all header of the same name.

[Yasuo Ohgaki]

Hi Stephen,

On Wed, Oct 19, 2016 at 12:18 PM, Stephen Reay  wrote:
> I still have an issue with that. I believe the correct behaviour here is 
> (assuming the `replace` argument to header() is honoured) what you’re seeing. 
> Yes, it might be *unexpected* for new users, but its also *expected* by 
> millions of current users/projects.
>
> I would suggest perhaps a warning on the header() docs page, and perhaps an 
> example to avoid the issue on the Session handling page.
>
> Leaving it as-is, with improved docs means all functionality is *possible* 
> with the right arguments.
>
> Changing to your proposal means advanced use-cases are *impossible* with any 
> arguments.
>
>
> I realise you’re trying to remove WTF cases, but I don’t think removing 
> advanced capabilities is the way to do that.

Yes. Even framework developer(?) seems to have current behavior.

In general, users shouldn't touch session ID. In case of user really
want to modify session ID cookie, following could be done.



Make header_remove() able to delete 'Set-Cookie' header. (Current behavior)
Make header() able to send 'Set-Cookie' header. (Current behavior, but
not remove session ID cookie)

This allows users to send arbitrary session ID cookie when it is
needed really needed, while avoiding accidental session ID cookie
removal.

What do you think?

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] Re: header() removes all header of the same name.

[Stephen Reay]

Hi Yasuo,

I still have an issue with that. I believe the correct behaviour here is 
(assuming the `replace` argument to header() is honoured) what you’re seeing. 
Yes, it might be *unexpected* for new users, but its also *expected* by 
millions of current users/projects.

I would suggest perhaps a warning on the header() docs page, and perhaps an 
example to avoid the issue on the Session handling page.

Leaving it as-is, with improved docs means all functionality is *possible* with 
the right arguments.

Changing to your proposal means advanced use-cases are *impossible* with any 
arguments.


I realise you’re trying to remove WTF cases, but I don’t think removing 
advanced capabilities is the way to do that.


Cheers

Stephen


> On 19 Oct 2016, at 08:00, Yasuo Ohgaki  wrote:
> 
> Hi all,
> 
> On Tue, Oct 18, 2016 at 4:31 PM, Yasuo Ohgaki  wrote:
>> I understand why header() is made to remove all headers of the same
>> name. This is needed in some cases, but it does not work well for some
>> cases.
>> 
>> We need to decide what to do with
>> https://bugs.php.net/bug.php?id=72997
>> 
>> There is 2 issues.
>>  - header() removes all headers of the same name including 'Set-Cookie'
>>  - header() ignores replace flag. (This one is easy to fix)
>> 
>> Since header() enables 'replace flag' by default, it removes all
>> 'Set-Cookie' headers sent previously by default. It can easily disturb
>> security related cookies to work. i.e. Session ID cookie, Auto Login
>> cookie. This bug would be very hard to find for normal users, too.
>> 
>> Restoring older behavior (Removing only one header) cannot be a
>> resolution because it can still disturb security related cookies.
>> 
>> Possible resolutions:
>> 
>> - Prohibit 'Set-Cookie' for header() and force users to use setcookie()
>> - Mitigate by disabling replace flag by default. (This is not a good idea, 
>> IMO)
>> 
>> Both resolution requires BC, but this is better to be fixed ASAP.
>> 
>> Non-BC resolution could be:
>>  - "Ask users to use setcookie() always for 'Set-Cookie'".
>> 
>> I would like to prohibit 'Set-Cookie' by header() because it may
>> remove session ID cookie as well as auto login cookie, etc. If we
>> leave released version as it is now, I would like to prohibit
>> 'Set-Cookie' by header() in PHP 7.1.
>> 
>> Problem with this may be that user cannot modify 'Set-Cookie' header
>> line as user want.
>> 
>> $ php -r 'setcookie("REMEMBERME=value; expires=Sat, 03-Sep-2020
>> 05:38:43 GMT; path=/; domain=aaa");'
>> PHP Warning:  Cookie names cannot contain any of the following '=,;
>> \t\r\n\013\014' in Command line code on line 1
>> 
>> 
>> Comments?
> 
> An idea for session ID protection.
> 
> Following code results in lost session always.
> 
>  session_start();
> session_regenerate_id();
> header('Set-Cookie: something');
> ?>
> 
> header() function removes all header of the same name, e.g.
> Set-Cookie, Expires, etc, by sapi_remove_header(). This could be very
> hard to find the cause.
> 
> 
> This risk can be removed w/o much BC. Only BC is when user is
> intentionally trying to delete session ID cookie manually. This would
> be very rare. We can add code that excludes session ID cookie in
> sapi_remove_header().
> http://lxr.php.net/xref/PHP-MASTER/main/SAPI.c#593
> 
> To do that, we can search string like following
> Set-Cookie: PHPSESSID=xxx
> 
> The only issue is we need session global, i.e. PS(session_name), at
> least. It's not nice to have dependency from SAPI.c to session, but it
> protects session ID from removed by users by mistake.
> 
> Any comments?
> 
> Regards,
> 
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
> 
> -- 
> 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] Re: header() removes all header of the same name.

[Yasuo Ohgaki]

Hi all,

On Tue, Oct 18, 2016 at 4:31 PM, Yasuo Ohgaki  wrote:
> I understand why header() is made to remove all headers of the same
> name. This is needed in some cases, but it does not work well for some
> cases.
>
> We need to decide what to do with
> https://bugs.php.net/bug.php?id=72997
>
> There is 2 issues.
>   - header() removes all headers of the same name including 'Set-Cookie'
>   - header() ignores replace flag. (This one is easy to fix)
>
> Since header() enables 'replace flag' by default, it removes all
> 'Set-Cookie' headers sent previously by default. It can easily disturb
> security related cookies to work. i.e. Session ID cookie, Auto Login
> cookie. This bug would be very hard to find for normal users, too.
>
> Restoring older behavior (Removing only one header) cannot be a
> resolution because it can still disturb security related cookies.
>
> Possible resolutions:
>
>  - Prohibit 'Set-Cookie' for header() and force users to use setcookie()
>  - Mitigate by disabling replace flag by default. (This is not a good idea, 
> IMO)
>
> Both resolution requires BC, but this is better to be fixed ASAP.
>
> Non-BC resolution could be:
>   - "Ask users to use setcookie() always for 'Set-Cookie'".
>
> I would like to prohibit 'Set-Cookie' by header() because it may
> remove session ID cookie as well as auto login cookie, etc. If we
> leave released version as it is now, I would like to prohibit
> 'Set-Cookie' by header() in PHP 7.1.
>
> Problem with this may be that user cannot modify 'Set-Cookie' header
> line as user want.
>
> $ php -r 'setcookie("REMEMBERME=value; expires=Sat, 03-Sep-2020
> 05:38:43 GMT; path=/; domain=aaa");'
> PHP Warning:  Cookie names cannot contain any of the following '=,;
> \t\r\n\013\014' in Command line code on line 1
>
>
> Comments?

An idea for session ID protection.

Following code results in lost session always.



header() function removes all header of the same name, e.g.
Set-Cookie, Expires, etc, by sapi_remove_header(). This could be very
hard to find the cause.


This risk can be removed w/o much BC. Only BC is when user is
intentionally trying to delete session ID cookie manually. This would
be very rare. We can add code that excludes session ID cookie in
sapi_remove_header().
http://lxr.php.net/xref/PHP-MASTER/main/SAPI.c#593

To do that, we can search string like following
Set-Cookie: PHPSESSID=xxx

The only issue is we need session global, i.e. PS(session_name), at
least. It's not nice to have dependency from SAPI.c to session, but it
protects session ID from removed by users by mistake.

Any comments?

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] Bug fix and RFC/Merge rule

[Yasuo Ohgaki]

Hi Pierre,

On Wed, Oct 19, 2016 at 9:52 AM, Pierre Joye  wrote:
> Like your session change, while not really critical to me (has been
> like that for ages) is relatively logical while as a RM, I would not

It's off topic, but I'll paste answer to a question regarding
session.use_strict_mode. i.e. session ID validation. I recently got
this question personally.

> I have a question regarding this quite old RFC - my question is, how was it 
> practically possible to attack a PHP app that uses sessions prior to PHP 
> 5.5.2?
> Doesn't it require the ability for the attackers to place an SID cookie in 
> the victim's browser?  How would they do that (assuming trans_sid is off)?

Possible scenarios are:
 - Attacker sets SID by XSS. (Set cookies via JavaScript)
 - Physical access to victim's device. (e.g. Friends, Colleague
attacker, Shared PC)
 - Compromised network. (WiFi access point, ARP spoofing)

When aboves are the case, attacker may set malicious cookies including
unchangeable cookies.

I think this answers to your question. Followings are additional info.

Malicious active SID is security risk even without authentication.
e.g. Shopping sites may store user info (name, address, purchased
product, etc) w/o authentication to enable shopping without user
registration. Another example is session ID has meaning. e.g. User ID
prefixed session that I'm currently proposing. Attacker may set
attacker generated SIDs that includes user ID for system's checks max
number of active session per user, and perform personal DoS attacks.

Another possible attack scenario is broken session_regenerate_id()
usage. When session_regenerate_id() is used properly, attacker cannot
gain authenticated session ID. However, if user is aware of risks of
session management w/o timestamp and try to set timestamp by
him/herself, the code could be broken by mistakes, and PHP may keep
using attacker set session ID, and attacker may gain authenticated
session ID. (Or more simpler, program didn't call
session_regenerate_id() at all, or at least call improperly)

When latter scenario is effective, attacker can set undeletable
session ID cookie, and attacker may gain authenticated session almost
forever.

To remove risks,
 - Enable use_strict_session (Attackers cannot set their SIDs)
 - Make session_regenerate_id() can set programmer specified session
ID. (Need this because I can modify session_regenerate_id() work
safely w/o knowing session management details)
 - Adopt timestamp management via session data (i.e. $_SESSION) so
that programs can manage session data precisely.

I hope this helps!

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] Re: Fixing insane session_start() behaviors

[Pierre Joye]

Hi Yasuo,

On Mon, Oct 17, 2016 at 4:47 PM, Yasuo Ohgaki  wrote:
> Hi Davey,
>
> On Sun, Oct 16, 2016 at 6:08 PM, Yasuo Ohgaki  wrote:
>>
>> I was planning to fix session_start() behaviors by PHP 7.1, but I
>> forgot to do this completely. Partial fix is merged currently.
>>
>> Following PR makes session_start() return FALSE when it cannot start
>> session always.
>>
>> https://github.com/php/php-src/pull/2167
>>
>> In short, this patch fixes number of session_start()'s insane behaviors.
>
> I think I've finished the patch for now.
>
> There are many other places that I would like to improve/fix error
> handlings. e.g. Session save handlers. This patch is too large
> already. I'll fix them in master.
>
> The patch could be divided into "session_start() error handling fix
> only" and "other session core error handling issues". It may be good
> to include "session_start() error handling fix only" for PHP 7.1, but
> other fixes won't bother correct PHP scripts. Please note that
> session_start() fix in PHP-7.1 and master branch is partial fix. I
> suggest to merge "session_start() error handling fix only" at least,
> but it's your choice.
>
> Please let me know when you decide what to do or merge appropriate
> patch from the PR.
>
> BTW, I expect UnitTest failures, framework/etc, that test session
> module functionalities. They have tests for failure cases. Even if
> there are minor BC issues (UnitTests report error, bad code emit
> errors), this fix must be done at some point anyway.

I like this change as it adds some cleanup and common sense to this
API. However 7.1 is in RC, this patch, while covering logical changes,
affect behaviors and is quite big (lot of similar changes but still).
I would feel much more comfortable to push it after 7.1 (as in, for
7.2 and later).

Cheers,
-- 
Pierre

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

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

Re: [PHP-DEV] Bug fix and RFC/Merge rule

[Pierre Joye]

hi Yasuo,

On Wed, Oct 19, 2016 at 4:41 AM, Yasuo Ohgaki  wrote:
> Hi all,
>
> Following commit is reverted because someone requested "RFC" and/or
> demand "Merge approval from RM",

Yes, this is the rule for non obvious things. Or no matter what for
stable branches in security mode or RC phase.

> http://git.php.net/?p=php-src.git;a=commitdiff;h=48f1a17886d874dc90867c669481804de90509e8
>
> I don't understand the reasoning why it requires RFC nor Merge
> approval. As we all know, there are many bug fixes without RFC nor
> discussion.
>
> So let's discuss about what bug fix requires RFC and merge approval.
>
> The patch fixes "uniqid() is not unique enough" bug.
> ---
> ==Rationale==
> uniqid() is simply _broken_ because it does not provide expected uniqueness 
> due
> to timestamp based php_combined_lcg().
> (large warning is added to the manual recently)
>
> unique id (time stamp) + entropy (timestamp based entropy)
>
> Problems of this implementation
>   - NTP is used to adjust system time.
>   - Result is not reasonably unique by logic.
>
> ==Resolution==
>   Replace php_combined_lcg() (Poor PRNG) to php_random_bytes() (CSPRNG).
>
>   Patch
>   
> http://git.php.net/?p=php-src.git;a=commitdiff;h=48f1a17886d874dc90867c669481804de90509e8
>   (less than 30 lines of diff)
>
> ==BC impact==
>   There is no BC.  php_random_bytes() raises exception for bad CSPRNG,
>   but this very unlikely and such system shouldn't be used anyway.
> ---
>
> Discussions in previous thread
> ---
> =="new uniqid() can cause /dev/urandom cannot read error"==
>
> This is FUD. Almost all "/dev/urandom cannot read" issues on the net
> is due to "open_basedir" restriction. "open_basedir" is nothing to do
> with internal functions, so the discussion is FUD.
>
> =="Any new error is BC so the patch should be reverted"==
>
> We do have many bug fixes emit new errors. We don't revert them at all
> even when it's very common and annoying.
>
> Example:  https://bugs.php.net/bug.php?id=73238
> This bug fix made WordPress display few additional E_WARNING errors
> that can be remove by php.ini or code fix.
>
> =="Someone explicitly requested RFC/Merge approval, so it should be 
> reverted"==
>
> IMHO, the patch is very simple patch only fixes problem. Many bug
> fixes include more severe BC issues than the patch, behavior changes
> and raised errors. Yet, no RFC nor discussions.
>
> If someone requested RFC/Merge request for very simple patch, should
> we follow always?
>
> =="It does not have to hurry"==
>
> I agree with this. However, reverting simple bug fix patch does not make 
> sense.
> --
>
> Question is:
>   - What kind of bug fix requires RFC?

No behavior change, strong consensus, no BC break. But really a case
by case question.

>   - What kind of bug fix requires discussion and approval to merge
> released versions?

Same answer.

>
> After all, my question is "Should we discuss all bugs before commits?"
> "The revert is valid and reasonable?"

The main point is what is a bug, what is a BC break. And we had many
different opinions in the past. Even in this case where "this system
should not be used anyway" makes me wonder.

Like your session change, while not really critical to me (has been
like that for ages) is relatively logical while as a RM, I would not
merge it in 7.1 at this stage (RC).

Cheers,
Pierre

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

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Yasuo Ohgaki]

On Wed, Oct 19, 2016 at 8:01 AM, Anatol Belski  wrote:
>> -Original Message-
>> From: Yasuo Ohgaki [mailto:yohg...@ohgaki.net]
>> Sent: Tuesday, October 18, 2016 9:53 PM
>> To: Anatol Belski 
>> Cc: Joe Watkins ; Niklas Keller ;
>> Leigh ; PHP Internals 
>> Subject: Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness
>>
>> Hi Anatol,
>>
>> On Wed, Oct 19, 2016 at 1:41 AM, Anatol Belski  wrote:
>> > AFM the patch is not acceptable for 7.0. It is true that some place was 
>> > moved
>> to the new random int functionality (in password AFAIR). But, it is done at 
>> the
>> place and the way that a BC breach is unlikely. Using the throwing variant 
>> is for
>> sure a BC breach, but also the way pushing while being explicitly asked to go
>> through an RFC, is inappropriate. As the new random_* functions are available
>> and allow to implement the best possible uniqueness in user land, changing 
>> the
>> algorithm of the existing uniqid() doesn't look to have a valid base.
>> >
>>
>> Any additional error could be BC. It's the fact.
>>
>> However, your sentence does not make sense at all.
>> Do we revert any error emitting bug fix? No, not at all.
>>
> As far as I remember, uniqid() was never meant to be cryptographically safe. 
> It is documented. Indeed systems might be too fast for microseconds based 
> function nowadays. In 7.0, my simple exercise -  substr(md5(random_bytes(8)), 
> 0, 13) which does same in the way you want it. We are talking about a 
> oneliner of new code vs. an old function that is guaranteed in use at any 
> possible places.

The original draft RFC proposal aimed to be cryptographically safe
unique ID as much as it can, but the pushed patch is not.

>
>> We do  add errors as normal bug fix process. Many of them are w/o RFC, even
>> w/o discussion.
>>
>> Example: https://bugs.php.net/bug.php?id=73238
>> This bug fix caused WordPress caused 3 additional E_WARNING displayed that
>> can be remove by php.ini or code fix.
>>
> As a reminder - there's no global rule about functions throwing exceptions, 
> so it is not done by default. Except a couple of new places, no function 
> throws an exception. The place in password salt code, that was migrated to 
> the new randomness, did already depend on /dev/urandom and others. However, 
> even it's based on the new functionality, the old behavior is kept and it is 
> done intentionally.

I agree that this apply to cases such as rand(). We do had to keep
rand() behavior even if it produces very bad random on Windows, as you
know well.
Replacing bad entropy that should be "really random" is different story.

Current uniqid('', true)'s result is:

unique id (time stamp) + entropy (timestamp based entropy)

Isn't this a shame of us providing the result as "uniqid()" call?

(I'm not saying original design is bad. Original design was inevitable
due to technical limitation, historical reason, just like Windows
rand()) Entropy is entropy. As long as format is kept, it does not
matter if we use better entropy.

>
>> Which is important?
>>  - uniqid() is not unique
>>  - Really broken system that shouldn't be used may emit error
>>
>> "/dev/urandom cannot read discussion" is FUD and irrelevant to this 
>> discussion.
>> Issues with user script random_bytes() implementation or like does not apply 
>> to
>> uniqid() fix.
>>
> But your implementation indeed uses another API that has other impacts. 
> Php_random_bytes is crossplatform, there can be various errors on various 
> platforms. That's the concern as I'd understand it.
>
>>
>> Anyway, are we going to revert anything emit new errors from now on because
>> it's BC?
>> Are we going to require RFC for this kind of very simple and reasonable fix?
>> I hope not.
>>
>> IMHO my discussion is logical. Please consider revert the revert.
>> Otherwise, we cannot fix even simple bugs.
>>
> No, IMHO you overdo it a bit. Of course it is acceptable with errors, 
> warning, etc. where it makes sense. But it needs a base and a balance also in 
> other areas for usability, performance, BC, language consistency, etc. If one 
> were telling, it's impossible to do it in PHP - but there are functions in 
> PHP 7, that provide the functionality aimed. Yes, there is also some legacy 
> functionality, so should everything be moved to cryptographically safe? The 
> answer is obviously - no. For crypto there are dedicated functions and 
> extensions there. Besides that, you see many other people opposing this 
> change. An RFC were the way to target the PHP version you want, even 7.0. As 
> for me, I'd likely vote yes for master, if the throwing part were replaced.

I think you and Joe could not follow the discussion. It's okay,
reading them all is waste of your time. I read all, but I'm not sure
if I understand/remember all of them well.

IMHO Oppositions for 

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

[Daniel Morris]

And sorry for the  spam (this should have been mentioned in the last
email), as far as I can tell, there is no-way to say "I want a either a
signed or unsigned integer with an N bits", I've come across this
recently whilst trying to implement Murmur3 (128-bit) in PHP, I can
of-course binary AND into
0b111 (e.g.
$x & 0b11...) and it will yield result of 9,223,372,036,854,775,807
((2^63)- 1 (PHP_INT_MAX)) but adding an additional 1 (radix 10) will
yield a double(9.2233720368548E+18) and it's at that point it becomes
incredibly difficult to work with to work with natural numbers.

(Unrelated to Sara's RFC, just a thought I'd mention incase someone is
interested...)

I personally think this RFC is fine despite the existing libraries that
do similar (BCMath and GMP), it's more of an interface to the lower
layer (and OpenSSL specific) rather than an implementation. We're just
keeping up with existing implementations.

Sara, I'm happy to implement additional tests and look at fast ZPP for
methods tomorrow if you're too busy and think this is going somewhere...

DM

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

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

[Daniel Morris]

On Tue, 18 Oct 2016, at 09:22 AM, Nikita Popov wrote:
> On Tue, Oct 18, 2016 at 3:35 AM, Sara Golemon  wrote:
> 
> > As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.

Why do we need GMP when we have BCMath? GMP is faster (from what I've
seen so far from various tests and blog posts) – whilst they do similar
ops, they are chosen for specific reasons, all this does is expose the
existing interfaces for arbitrary precision arithmetic made available
with the OpenSSL layer, and I think anyone implementing them would want
the API there, it requires minimal maintenance. Sara, I think the best
route is too match the method names within OpenSSL, it will avoid some
initial confusion, unless people want to change libraries, but I think
that is probably less likely.

DM

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

Re: [PHP-DEV] Re: lxr.php.net is coming soon.... finally....

[Christoph M. Becker]

On 19.10.2016 at 00:07, Ferenc Kovacs wrote:

> On Tue, Oct 18, 2016 at 9:14 PM, Rowan Collins 
> wrote:
> 
>> Looks like it's generating slightly the wrong link for some reason: it
>> goes to http://lxr.php.net/source/s?defs=php_info_print_table_row
>> oject=PHP-MASTER but the "/source" segment shouldn't be there. It works
>> if you remove it: http://lxr.php.net/s?defs=php_
>> info_print_table_row=PHP-MASTER
>>
>> My guess would be something to do with rewrite rules, and the "source"
>> directory exists on disk but isn't supposed to be part of the URL.
> 
> hi, yeah, on Tomcat the opengrok app is called source, I've the changed the
> settings so now that it works both with and without /source in the url.

Works fine now.  Thank you very much!

-- 
Christoph M. Becker


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

[PHP-DEV] Re: Bug fix and RFC/Merge rule

[Christoph M. Becker]

Hi Yasuo!

On 18.10.2016 at 23:41, Yasuo Ohgaki wrote:

> After all, my question is "Should we discuss all bugs before commits?"

No, I don't think that would be reasonable for time reasons.  However,
if someone steps in, raising doubts about a certain bug fix, that has to
be discussed and if no consensus can be found, an RFC seems to be the
most sensible way to resolve the issue.  Until the RFC has been decided
upon, (temporarily) reverting the commit also makes sense, in my
opinion. :-)

-- 
Christoph M. Becker

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

RE: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Anatol Belski]

Yasuo,

> -Original Message-
> From: Yasuo Ohgaki [mailto:yohg...@ohgaki.net]
> Sent: Tuesday, October 18, 2016 9:53 PM
> To: Anatol Belski 
> Cc: Joe Watkins ; Niklas Keller ;
> Leigh ; PHP Internals 
> Subject: Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness
> 
> Hi Anatol,
> 
> On Wed, Oct 19, 2016 at 1:41 AM, Anatol Belski  wrote:
> > AFM the patch is not acceptable for 7.0. It is true that some place was 
> > moved
> to the new random int functionality (in password AFAIR). But, it is done at 
> the
> place and the way that a BC breach is unlikely. Using the throwing variant is 
> for
> sure a BC breach, but also the way pushing while being explicitly asked to go
> through an RFC, is inappropriate. As the new random_* functions are available
> and allow to implement the best possible uniqueness in user land, changing the
> algorithm of the existing uniqid() doesn't look to have a valid base.
> >
> 
> Any additional error could be BC. It's the fact.
> 
> However, your sentence does not make sense at all.
> Do we revert any error emitting bug fix? No, not at all.
> 
As far as I remember, uniqid() was never meant to be cryptographically safe. It 
is documented. Indeed systems might be too fast for microseconds based function 
nowadays. In 7.0, my simple exercise -  substr(md5(random_bytes(8)), 0, 13) 
which does same in the way you want it. We are talking about a oneliner of new 
code vs. an old function that is guaranteed in use at any possible places. 

> We do  add errors as normal bug fix process. Many of them are w/o RFC, even
> w/o discussion.
> 
> Example: https://bugs.php.net/bug.php?id=73238
> This bug fix caused WordPress caused 3 additional E_WARNING displayed that
> can be remove by php.ini or code fix.
> 
As a reminder - there's no global rule about functions throwing exceptions, so 
it is not done by default. Except a couple of new places, no function throws an 
exception. The place in password salt code, that was migrated to the new 
randomness, did already depend on /dev/urandom and others. However, even it's 
based on the new functionality, the old behavior is kept and it is done 
intentionally.

> Which is important?
>  - uniqid() is not unique
>  - Really broken system that shouldn't be used may emit error
> 
> "/dev/urandom cannot read discussion" is FUD and irrelevant to this 
> discussion.
> Issues with user script random_bytes() implementation or like does not apply 
> to
> uniqid() fix.
> 
But your implementation indeed uses another API that has other impacts. 
Php_random_bytes is crossplatform, there can be various errors on various 
platforms. That's the concern as I'd understand it.

> 
> Anyway, are we going to revert anything emit new errors from now on because
> it's BC?
> Are we going to require RFC for this kind of very simple and reasonable fix?
> I hope not.
> 
> IMHO my discussion is logical. Please consider revert the revert.
> Otherwise, we cannot fix even simple bugs.
> 
No, IMHO you overdo it a bit. Of course it is acceptable with errors, warning, 
etc. where it makes sense. But it needs a base and a balance also in other 
areas for usability, performance, BC, language consistency, etc. If one were 
telling, it's impossible to do it in PHP - but there are functions in PHP 7, 
that provide the functionality aimed. Yes, there is also some legacy 
functionality, so should everything be moved to cryptographically safe? The 
answer is obviously - no. For crypto there are dedicated functions and 
extensions there. Besides that, you see many other people opposing this change. 
An RFC were the way to target the PHP version you want, even 7.0. As for me, 
I'd likely vote yes for master, if the throwing part were replaced. 

Regards

Anatol



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

Re: [PHP-DEV] Re: lxr.php.net is coming soon.... finally....

[Ferenc Kovacs]

On Tue, Oct 18, 2016 at 9:14 PM, Rowan Collins 
wrote:

> On 18/10/2016 11:43, Christoph M. Becker wrote:
>
>> On 18.10.2016 at 09:07, Ferenc Kovacs wrote:
>>
>> the initial setup is done, let me know what did I miss.
>>>
>> Thanks, Ferenc.  It seems that the navigation to symbols in another file
>> is broken.  Consider, for instance,
>> .  Clicking on
>> php_info_print_table_row gives
>>
>> | Error: File not found!
>> |
>> | The requested resource is not available
>>
>> That also happens for all other identifiers located in other files that
>> I tried.  Don't know what's wrong there.
>>
>>
> Looks like it's generating slightly the wrong link for some reason: it
> goes to http://lxr.php.net/source/s?defs=php_info_print_table_row
> oject=PHP-MASTER but the "/source" segment shouldn't be there. It works
> if you remove it: http://lxr.php.net/s?defs=php_
> info_print_table_row=PHP-MASTER
>
> My guess would be something to do with rewrite rules, and the "source"
> directory exists on disk but isn't supposed to be part of the URL.
>

hi, yeah, on Tomcat the opengrok app is called source, I've the changed the
settings so now that it works both with and without /source in the url.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] [RFC] Driver-Specific PDO Param Types

[Adam Baratz]

Hi,

I've created an RFC to change how types are defined in PDO:
https://wiki.php.net/rfc/driver-specific-pdo-param-types

Please share your feedback. I'm happy to hear thoughts about the pdo_dblib
example, but the RFC is more about the possibility of driver-specific types
than these particular ones.

Thanks,
Adam

[PHP-DEV] Bug fix and RFC/Merge rule

[Yasuo Ohgaki]

Hi all,

Following commit is reverted because someone requested "RFC" and/or
demand "Merge approval from RM",

http://git.php.net/?p=php-src.git;a=commitdiff;h=48f1a17886d874dc90867c669481804de90509e8

I don't understand the reasoning why it requires RFC nor Merge
approval. As we all know, there are many bug fixes without RFC nor
discussion.

So let's discuss about what bug fix requires RFC and merge approval.

The patch fixes "uniqid() is not unique enough" bug.
---
==Rationale==
uniqid() is simply _broken_ because it does not provide expected uniqueness due
to timestamp based php_combined_lcg().
(large warning is added to the manual recently)

unique id (time stamp) + entropy (timestamp based entropy)

Problems of this implementation
  - NTP is used to adjust system time.
  - Result is not reasonably unique by logic.

==Resolution==
  Replace php_combined_lcg() (Poor PRNG) to php_random_bytes() (CSPRNG).

  Patch
  
http://git.php.net/?p=php-src.git;a=commitdiff;h=48f1a17886d874dc90867c669481804de90509e8
  (less than 30 lines of diff)

==BC impact==
  There is no BC.  php_random_bytes() raises exception for bad CSPRNG,
  but this very unlikely and such system shouldn't be used anyway.
---

Discussions in previous thread
---
=="new uniqid() can cause /dev/urandom cannot read error"==

This is FUD. Almost all "/dev/urandom cannot read" issues on the net
is due to "open_basedir" restriction. "open_basedir" is nothing to do
with internal functions, so the discussion is FUD.

=="Any new error is BC so the patch should be reverted"==

We do have many bug fixes emit new errors. We don't revert them at all
even when it's very common and annoying.

Example:  https://bugs.php.net/bug.php?id=73238
This bug fix made WordPress display few additional E_WARNING errors
that can be remove by php.ini or code fix.

=="Someone explicitly requested RFC/Merge approval, so it should be reverted"==

IMHO, the patch is very simple patch only fixes problem. Many bug
fixes include more severe BC issues than the patch, behavior changes
and raised errors. Yet, no RFC nor discussions.

If someone requested RFC/Merge request for very simple patch, should
we follow always?

=="It does not have to hurry"==

I agree with this. However, reverting simple bug fix patch does not make sense.
--

Question is:
  - What kind of bug fix requires RFC?
  - What kind of bug fix requires discussion and approval to merge
released versions?

It does not have to be generic. It's okay for providing reasons why
this specific bug fix requires RFC or merge approval. If this bug fix
requires RFC or merge approval, almost all bug fixes requires RFC and
merge approval.

Thank you.



P.S.
The original discussion is done in "[RFC][DISCUSSION] Improve uniqid()
uniqueness" thread.

After all, my question is "Should we discuss all bugs before commits?"
"The revert is valid and reasonable?"


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

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

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Yasuo Ohgaki]

Hi Rowan,

On Wed, Oct 19, 2016 at 5:14 AM, Rowan Collins  wrote:
> On 18/10/2016 20:52, Yasuo Ohgaki wrote:
>>
>> Which is important?
>>   - uniqid() is not unique
>>   - Really broken system that shouldn't be used may emit error
>
>
> Frankly, both are pretty rare cases. From the way you talk about it,
> everybody who uses uniqid() will get duplicate values all the time, when in
> fact, it's incredibly unlikely that anyone will even notice.
>
> I know when I've used it, it's for things like avoiding duplicate id
> attributes on an HTML page, or varying the URL of an asset by adding a token
> to the URL. It's perfectly usable as is for those situations, and I use it
> with full knowledge that it has a small chance of generating colliding
> values.
>
> I'm happy to see it improved, but I don't see any hurry, unless I'm
> completely misunderstanding the chances of seeing collisions.

This is reasonable discussion.

I do use uniqid() for HTML id attributes. It is difficult to detect id
collisions
since it's not server side. (Technically it can, but it requires more resources)
While it works almost always, but it should be better than now. Otherwise,
I'm very uncomfortable with uniqid().

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] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Rowan Collins]

On 18/10/2016 20:52, Yasuo Ohgaki wrote:

Which is important?
  - uniqid() is not unique
  - Really broken system that shouldn't be used may emit error


Frankly, both are pretty rare cases. From the way you talk about it, 
everybody who uses uniqid() will get duplicate values all the time, when 
in fact, it's incredibly unlikely that anyone will even notice.


I know when I've used it, it's for things like avoiding duplicate id 
attributes on an HTML page, or varying the URL of an asset by adding a 
token to the URL. It's perfectly usable as is for those situations, and 
I use it with full knowledge that it has a small chance of generating 
colliding values.


I'm happy to see it improved, but I don't see any hurry, unless I'm 
completely misunderstanding the chances of seeing collisions.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Yasuo Ohgaki]

Hi Kalle and all,

On Wed, Oct 19, 2016 at 1:43 AM, Kalle Sommer Nielsen  wrote:
> 2016-10-18 18:41 GMT+02:00 Anatol Belski :
>> AFM the patch is not acceptable for 7.0. It is true that some place was 
>> moved to the new random int functionality (in password AFAIR). But, it is 
>> done at the place and the way that a BC breach is unlikely. Using the 
>> throwing variant is for sure a BC breach, but also the way pushing while 
>> being explicitly asked to go through an RFC, is inappropriate. As the new 
>> random_* functions are available and allow to implement the best possible 
>> uniqueness in user land, changing the algorithm of the existing uniqid() 
>> doesn't look to have a valid base.
>
> I must add, despite not following the discussion entirely, that it
> should also be approved by the two 7.1 RMs to be committed,
> considering we are in RC4 stage at this point and I don't think we
> should just commit things this late without the RM consent to it.

This is usually I do. You'll see my mails discussing which branches to
merge that is not simple. For almost all bug fixes, I do not see
discussion for merging released branchs.

(Following questions are not for Kalle)

Most bug fixes are not discussed at all here.
What is making this simple bug special?

What's wrong with this simple fix?
What makes this a special requires RFC?
---
The patch committed is pure bug fix.

uniqid() is simply _broken_ because it does not provide expected uniqueness due
to timestamp based php_combined_lcg(). (I added large warning to the manual
recently, though)

unique id (time stamp) + entropy (timestamp based entropy)

Who argue result is reasonably unique?
Who don't use NTP to adjust system time?
---

If any new errors cannot be tolerated with bug fix, are we going to
revert any bug fixes with new error?
Besides, "uniqid() will emit error because it uses /dev/urandom" is
FUD, isn't it?

If there is no reasonable / logical answers for these,
The patch should be included PHP 7.0 and up.


BTW, who really think the patch is offending patch to be merged to
released branches?
Please raise your hand now. I don't think there are many.

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] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Yasuo Ohgaki]

Hi Anatol,

On Wed, Oct 19, 2016 at 1:41 AM, Anatol Belski  wrote:
> AFM the patch is not acceptable for 7.0. It is true that some place was moved 
> to the new random int functionality (in password AFAIR). But, it is done at 
> the place and the way that a BC breach is unlikely. Using the throwing 
> variant is for sure a BC breach, but also the way pushing while being 
> explicitly asked to go through an RFC, is inappropriate. As the new random_* 
> functions are available and allow to implement the best possible uniqueness 
> in user land, changing the algorithm of the existing uniqid() doesn't look to 
> have a valid base.
>

Any additional error could be BC. It's the fact.

However, your sentence does not make sense at all.
Do we revert any error emitting bug fix? No, not at all.

We do  add errors as normal bug fix process. Many of them are w/o RFC,
even w/o discussion.

Example: https://bugs.php.net/bug.php?id=73238
This bug fix caused WordPress caused 3 additional E_WARNING displayed
that can be remove by php.ini or code fix.

Which is important?
 - uniqid() is not unique
 - Really broken system that shouldn't be used may emit error

"/dev/urandom cannot read discussion" is FUD and irrelevant to this
discussion. Issues with user script random_bytes() implementation or
like does not apply to uniqid() fix.


Anyway, are we going to revert anything emit new errors from now on
because it's BC?
Are we going to require RFC for this kind of very simple and reasonable fix?
I hope not.

IMHO my discussion is logical. Please consider revert the revert.
Otherwise, we cannot fix even simple bugs.

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] Constants for better double edge case handling

[Anatol Belski]

Hi Kalle,

> -Original Message-
> From: kalle@gmail.com [mailto:kalle@gmail.com] On Behalf Of Kalle
> Sommer Nielsen
> Sent: Tuesday, October 18, 2016 9:05 PM
> To: Anatol Belski 
> Cc: PHP Internals ; Davey Shafik ; Joe
> Watkins 
> Subject: Re: [PHP-DEV] Constants for better double edge case handling
> 
> Hi Anatol
> 
> 2016-10-18 20:46 GMT+02:00 Anatol Belski :
> > Hi,
> >
> > I would like to suggest adding the following constants
> >
> > REGISTER_MAIN_LONG_CONSTANT("PHP_DBL_DIG", DBL_DIG,
> > CONST_PERSISTENT | CONST_CS);
> > REGISTER_MAIN_DOUBLE_CONSTANT("PHP_DBL_MAX", DBL_MAX,
> > CONST_PERSISTENT | CONST_CS);
> > REGISTER_MAIN_DOUBLE_CONSTANT("PHP_DBL_MIN", DBL_MIN,
> > CONST_PERSISTENT | CONST_CS);
> > REGISTER_MAIN_DOUBLE_CONSTANT("PHP_DBL_EPSILON", DBL_EPSILON,
> > CONST_PERSISTENT | CONST_CS);
> >
> 
> I like this idea but I do think that we should name them PHP_DOUBLE_* or
> PHP_FLOAT_* (preferably the first).
> 
Ah, indeed. PHP_FLOAT_* is what is consistent, probably.

Thanks

Anatol



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

Re: [PHP-DEV] Re: lxr.php.net is coming soon.... finally....

[Rowan Collins]

On 18/10/2016 11:43, Christoph M. Becker wrote:

On 18.10.2016 at 09:07, Ferenc Kovacs wrote:


the initial setup is done, let me know what did I miss.

Thanks, Ferenc.  It seems that the navigation to symbols in another file
is broken.  Consider, for instance,
.  Clicking on
php_info_print_table_row gives

| Error: File not found!
|
| The requested resource is not available

That also happens for all other identifiers located in other files that
I tried.  Don't know what's wrong there.



Looks like it's generating slightly the wrong link for some reason: it 
goes to 
http://lxr.php.net/source/s?defs=php_info_print_table_row=PHP-MASTER 
but the "/source" segment shouldn't be there. It works if you remove it: 
http://lxr.php.net/s?defs=php_info_print_table_row=PHP-MASTER


My guess would be something to do with rewrite rules, and the "source" 
directory exists on disk but isn't supposed to be part of the URL.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] Constants for better double edge case handling

[Kalle Sommer Nielsen]

Hi Anatol

2016-10-18 20:46 GMT+02:00 Anatol Belski :
> Hi,
>
> I would like to suggest adding the following constants
>
> REGISTER_MAIN_LONG_CONSTANT("PHP_DBL_DIG", DBL_DIG, CONST_PERSISTENT |
> CONST_CS);
> REGISTER_MAIN_DOUBLE_CONSTANT("PHP_DBL_MAX", DBL_MAX, CONST_PERSISTENT |
> CONST_CS);
> REGISTER_MAIN_DOUBLE_CONSTANT("PHP_DBL_MIN", DBL_MIN, CONST_PERSISTENT |
> CONST_CS);
> REGISTER_MAIN_DOUBLE_CONSTANT("PHP_DBL_EPSILON", DBL_EPSILON,
> CONST_PERSISTENT | CONST_CS);
>

I like this idea but I do think that we should name them PHP_DOUBLE_*
or PHP_FLOAT_* (preferably the first).


-- 
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] Constants for better double edge case handling

[Anatol Belski]

Hi,

I would like to suggest adding the following constants 

REGISTER_MAIN_LONG_CONSTANT("PHP_DBL_DIG", DBL_DIG, CONST_PERSISTENT |
CONST_CS);
REGISTER_MAIN_DOUBLE_CONSTANT("PHP_DBL_MAX", DBL_MAX, CONST_PERSISTENT |
CONST_CS);
REGISTER_MAIN_DOUBLE_CONSTANT("PHP_DBL_MIN", DBL_MIN, CONST_PERSISTENT |
CONST_CS);
REGISTER_MAIN_DOUBLE_CONSTANT("PHP_DBL_EPSILON", DBL_EPSILON,
CONST_PERSISTENT | CONST_CS);

The goal of this is to improve the handling of double in the user land. Here
are a couple of usages to illustrate the idea.

The comparison of double values.

$d0 = sin(M_PI/6.0);
$d1 = .5;
var_dump(
$d0, $d1,
abs($d0 - $d1),
$d0 == $d1,
abs($d0 - $d1) < PHP_DBL_EPSILON
);

float(0.5)
float(0.5)
float(5.5511151231258E-17)
bool(false)
bool(true)


The rounding behavior, max possible value representable by the string
conversion.

$d = .2345234523453245324323465;
echo $d, " ", round($d, 20), " ", round($d, PHP_DBL_DIG);

0.23452345234532 0.23452345234532 0.23452345234533


Producing INF. There's currently no explicit way to produce INF and NAN,
whereby NAN is gettable with sqrt(-1).

echo PHP_DBL_MAX*PHP_DBL_MAX, " ", -PHP_DBL_MAX*PHP_DBL_MAX;
INF -INF


In general, it is more about the possibility to handle the edge cases
properly. While such cases would cause unnecessary overhead and likely a BC
breach with a direct core implementation, they'd be fine to handle in the
scripts where it comes to it. I think, at least DBL_DIG and DBL_EPSILON
should be mapped to the constants, to provide a base for more flexibility.
The change itself is pretty outspoken, so I'm not sure it requires an RFC. I
would target at least master with this. Or 7.1, if RMs are ok.

Regards

Anatol




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

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Kalle Sommer Nielsen]

2016-10-18 18:41 GMT+02:00 Anatol Belski :
> AFM the patch is not acceptable for 7.0. It is true that some place was moved 
> to the new random int functionality (in password AFAIR). But, it is done at 
> the place and the way that a BC breach is unlikely. Using the throwing 
> variant is for sure a BC breach, but also the way pushing while being 
> explicitly asked to go through an RFC, is inappropriate. As the new random_* 
> functions are available and allow to implement the best possible uniqueness 
> in user land, changing the algorithm of the existing uniqid() doesn't look to 
> have a valid base.

I must add, despite not following the discussion entirely, that it
should also be approved by the two 7.1 RMs to be committed,
considering we are in RC4 stage at this point and I don't think we
should just commit things this late without the RM consent to it.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

RE: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Anatol Belski]

Hi Yasuo,

> -Original Message-
> From: Yasuo Ohgaki [mailto:yohg...@ohgaki.net]
> Sent: Tuesday, October 18, 2016 2:03 PM
> To: Joe Watkins 
> Cc: Niklas Keller ; Leigh ; PHP Internals
> 
> Subject: Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness
> 
> Hi Joe,
> 
> On Tue, Oct 18, 2016 at 8:30 PM, Yasuo Ohgaki  wrote:
> >
> > On Tue, Oct 18, 2016 at 7:32 PM, Joe Watkins 
> wrote:
> >>> This change should go through the standard RFC process and should be
> >>> targeted at 7.2+ (master) *only*.
> >>
> >>> Please check with the RMs before merging functionality changes into
> >>> release branches. All functionality changes need consent and
> >>> consensus. Bug fixes (that don't change functionality or break BC)
> >>> do not.
> >>
> >> You were told very specifically that the kinds of changes you
> >> proposed here require an RFC.
> >
> > This comment is for original proposal that _changes_ output format, isn't 
> > it?
> >
> > It simply switches entropy source which we already relied on.
> 
> As you can see from last minutes discussion.
> 
> "/dev/urandom cannot be read" is FUD.
> It's pure bug fix. (I intentionally made patch easy to extend used chars, 
> though)
> 
> Would you consider revert the revert?
> 
AFM the patch is not acceptable for 7.0. It is true that some place was moved 
to the new random int functionality (in password AFAIR). But, it is done at the 
place and the way that a BC breach is unlikely. Using the throwing variant is 
for sure a BC breach, but also the way pushing while being explicitly asked to 
go through an RFC, is inappropriate. As the new random_* functions are 
available and allow to implement the best possible uniqueness in user land, 
changing the algorithm of the existing uniqid() doesn't look to have a valid 
base.

Thanks.

Anatol


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

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-10-18

[lp_benchmark_robot]

Results for project PHP master, build date 2016-10-18 06:25:44+03:00
commit: 0a67b29
previous commit:abd2c04
revision date:  2016-10-18 09:14:57+09: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.10% -0.04%  0.21%  
  7.32%
:-|   Drupal 7.36 cgi -T1  0.17% -1.00% -2.10%  
  4.38%
:-|   MediaWiki 1.23.9 cgi -T5000  0.13%  0.29%  0.48%  
  3.84%
:-(   bench.php cgi -T100  0.13% -3.09% 28.88%  
 -1.56%
:-(  micro_bench.php cgi -T10  0.07% -2.97% 11.65%  
  5.06%
:-|  mandelbrot.php cgi -T100  0.07% -0.72% 31.30%  
 -9.76%
---

* Relative Standard Deviation (Standard Deviation/Average)

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

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: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Niklas Keller]

2016-10-18 14:41 GMT+02:00 Yasuo Ohgaki :

> Hi Niklas,
>
> On Tue, Oct 18, 2016 at 9:33 PM, Niklas Keller  wrote:
> > 2016-10-18 14:12 GMT+02:00 Yasuo Ohgaki :
> >>
> >> Hi Niklas,
> >>
> >> On Tue, Oct 18, 2016 at 9:08 PM, Niklas Keller  wrote:
> >> >>
> >> >> As you can see from last minutes discussion.
> >> >>
> >> >> "/dev/urandom cannot be read" is FUD.
> >> >> It's pure bug fix. (I intentionally made patch easy to extend used
> >> >> chars, though)
> >> >>
> >> >> Would you consider revert the revert?
> >> >
> >> >
> >> > This discussion shows there should be a RFC and a vote. I'd not
> consider
> >> > this a simple bug fix, after all it doesn't really fix it.
> >> >
> >> > If we want to fix it in core, we'd better include an UUID generation
> >> > mechanism than fixing uniq_id.
> >>
> >> UUID like uniqueness is not the subject of uniqid(), isn't it?
> >
> >
> > UUID = Universally Unique Identifier
> > uniqid = Generate a unique ID
> >
> > Where is uniqueness _not_ the subject of uniqid()?
> >
> >>
> >> As I wrote, it's simple bug fix.
> >
> >
> > The issue is that it doesn't fix it. Maybe it band aids. But it doesn't
> fix
> > uniqid.
> >
> > It's exactly why I proposed to better deprecate uniqid. We can do that in
> > 7.2 and provide UUIDs as a standardized and superior alternative.
>
> OK, I understand you prefer to deprecate uniqid(), but I guess
> uniqid() deprecation is less likely to be passed than improving
> uniqid() uniqueness with a little BC.
>
> If you search uniqid() usage, you'll see UUID is too much for many
> usages. uniqid() has it own use cases.
>
> Current uniqid() is not unique at all.


Right, and it's impossible to fix it without breaking BC, because really
fixing it would require more output.


> The patch simply fixes it by
> using proper entropy, no BC basically.
>

It might be fine committing this to master. But as you say, uniqid is
broken and I'd not consider it fixed with just changing the source of
entropy but leaving the output as is.


> What's wrong with this?
>

Committing it directly to a frozen branch is.

Regards, Niklas

---
> The patch committed is pure bug fix.
>
> uniqid() is simply _broken_ because it does not provide expected
> uniqueness due
> to timestamp based php_combined_lcg(). (I added large warning to the manual
> recently, though)
>
> unique id (time stamp) + entropy (timestamp based entropy)
>
> Who argue result is reasonably unique?
> Who don't use NTP to adjust system time?
> ---
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Yasuo Ohgaki]

Hi Niklas,

On Tue, Oct 18, 2016 at 9:33 PM, Niklas Keller  wrote:
> 2016-10-18 14:12 GMT+02:00 Yasuo Ohgaki :
>>
>> Hi Niklas,
>>
>> On Tue, Oct 18, 2016 at 9:08 PM, Niklas Keller  wrote:
>> >>
>> >> As you can see from last minutes discussion.
>> >>
>> >> "/dev/urandom cannot be read" is FUD.
>> >> It's pure bug fix. (I intentionally made patch easy to extend used
>> >> chars, though)
>> >>
>> >> Would you consider revert the revert?
>> >
>> >
>> > This discussion shows there should be a RFC and a vote. I'd not consider
>> > this a simple bug fix, after all it doesn't really fix it.
>> >
>> > If we want to fix it in core, we'd better include an UUID generation
>> > mechanism than fixing uniq_id.
>>
>> UUID like uniqueness is not the subject of uniqid(), isn't it?
>
>
> UUID = Universally Unique Identifier
> uniqid = Generate a unique ID
>
> Where is uniqueness _not_ the subject of uniqid()?
>
>>
>> As I wrote, it's simple bug fix.
>
>
> The issue is that it doesn't fix it. Maybe it band aids. But it doesn't fix
> uniqid.
>
> It's exactly why I proposed to better deprecate uniqid. We can do that in
> 7.2 and provide UUIDs as a standardized and superior alternative.

OK, I understand you prefer to deprecate uniqid(), but I guess
uniqid() deprecation is less likely to be passed than improving
uniqid() uniqueness with a little BC.

If you search uniqid() usage, you'll see UUID is too much for many
usages. uniqid() has it own use cases.

Current uniqid() is not unique at all. The patch simply fixes it by
using proper entropy, no BC basically.

What's wrong with this?
---
The patch committed is pure bug fix.

uniqid() is simply _broken_ because it does not provide expected uniqueness due
to timestamp based php_combined_lcg(). (I added large warning to the manual
recently, though)

unique id (time stamp) + entropy (timestamp based entropy)

Who argue result is reasonably unique?
Who don't use NTP to adjust system time?
---

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

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

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Niklas Keller]

2016-10-18 14:12 GMT+02:00 Yasuo Ohgaki :

> Hi Niklas,
>
> On Tue, Oct 18, 2016 at 9:08 PM, Niklas Keller  wrote:
> >>
> >> As you can see from last minutes discussion.
> >>
> >> "/dev/urandom cannot be read" is FUD.
> >> It's pure bug fix. (I intentionally made patch easy to extend used
> >> chars, though)
> >>
> >> Would you consider revert the revert?
> >
> >
> > This discussion shows there should be a RFC and a vote. I'd not consider
> > this a simple bug fix, after all it doesn't really fix it.
> >
> > If we want to fix it in core, we'd better include an UUID generation
> > mechanism than fixing uniq_id.
>
> UUID like uniqueness is not the subject of uniqid(), isn't it?
>

UUID = Universally Unique Identifier
uniqid = Generate a unique ID

Where is uniqueness _not_ the subject of uniqid()?


> As I wrote, it's simple bug fix.
>

The issue is that it doesn't fix it. Maybe it band aids. But it doesn't fix
uniqid.

It's exactly why I proposed to better deprecate uniqid. We can do that in
7.2 and provide UUIDs as a standardized and superior alternative.

Regards, Niklas


> ---
> The patch committed is pure bug fix.
>
> uniqid() is simply _broken_ because it does not provide expected
> uniqueness due
> to timestamp based php_combined_lcg(). (I added large warning to the manual
> recently, though)
>
> unique id (time stamp) + entropy (timestamp based entropy)
>
> Who argue result is reasonably unique?
> Who don't use NTP to adjust system time?
> ---
>
> 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] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Yasuo Ohgaki]

Hi Niklas,

On Tue, Oct 18, 2016 at 9:08 PM, Niklas Keller  wrote:
>>
>> As you can see from last minutes discussion.
>>
>> "/dev/urandom cannot be read" is FUD.
>> It's pure bug fix. (I intentionally made patch easy to extend used
>> chars, though)
>>
>> Would you consider revert the revert?
>
>
> This discussion shows there should be a RFC and a vote. I'd not consider
> this a simple bug fix, after all it doesn't really fix it.
>
> If we want to fix it in core, we'd better include an UUID generation
> mechanism than fixing uniq_id.

UUID like uniqueness is not the subject of uniqid(), isn't it?

As I wrote, it's simple bug fix.
---
The patch committed is pure bug fix.

uniqid() is simply _broken_ because it does not provide expected uniqueness due
to timestamp based php_combined_lcg(). (I added large warning to the manual
recently, though)

unique id (time stamp) + entropy (timestamp based entropy)

Who argue result is reasonably unique?
Who don't use NTP to adjust system time?
---

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] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Niklas Keller]

2016-10-18 14:02 GMT+02:00 Yasuo Ohgaki :

> Hi Joe,
>
> On Tue, Oct 18, 2016 at 8:30 PM, Yasuo Ohgaki  wrote:
> >
> > On Tue, Oct 18, 2016 at 7:32 PM, Joe Watkins 
> wrote:
> >>> This change should go through the standard RFC process and should be
> >>> targeted at 7.2+ (master) *only*.
> >>
> >>> Please check with the RMs before merging functionality changes into
> >>> release
> >>> branches. All functionality changes need consent and consensus. Bug
> fixes
> >>> (that don't change functionality or break BC) do not.
> >>
> >> You were told very specifically that the kinds of changes you proposed
> here
> >> require an RFC.
> >
> > This comment is for original proposal that _changes_ output format,
> isn't it?
> >
> > It simply switches entropy source which we already relied on.
>
> As you can see from last minutes discussion.
>
> "/dev/urandom cannot be read" is FUD.
> It's pure bug fix. (I intentionally made patch easy to extend used
> chars, though)
>
> Would you consider revert the revert?
>

This discussion shows there should be a RFC and a vote. I'd not consider
this a simple bug fix, after all it doesn't really fix it.

If we want to fix it in core, we'd better include an UUID generation
mechanism than fixing uniq_id.

Regards, Niklas


> 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] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Yasuo Ohgaki]

Hi Joe,

On Tue, Oct 18, 2016 at 8:30 PM, Yasuo Ohgaki  wrote:
>
> On Tue, Oct 18, 2016 at 7:32 PM, Joe Watkins  wrote:
>>> This change should go through the standard RFC process and should be
>>> targeted at 7.2+ (master) *only*.
>>
>>> Please check with the RMs before merging functionality changes into
>>> release
>>> branches. All functionality changes need consent and consensus. Bug fixes
>>> (that don't change functionality or break BC) do not.
>>
>> You were told very specifically that the kinds of changes you proposed here
>> require an RFC.
>
> This comment is for original proposal that _changes_ output format, isn't it?
>
> It simply switches entropy source which we already relied on.

As you can see from last minutes discussion.

"/dev/urandom cannot be read" is FUD.
It's pure bug fix. (I intentionally made patch easy to extend used
chars, though)

Would you consider revert the revert?

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] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Yasuo Ohgaki]

On Tue, Oct 18, 2016 at 8:47 PM, Lester Caine  wrote:
> On 18/10/16 12:37, Yasuo Ohgaki wrote:
>> The patch committed is pure bug fix.
> https://www.google.co.uk/search?q=%2Fdev%2Furandom+is+not+readable+by+php
>
> Even bug fixes need proper documentation to avoid the WTF !

I'm about to add the doc.

Anyway, this is due to "open_basedir" restriction.
"open_basedir" does not affect php_random_bytes() at all.

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] Counting of non-countable objects

[Christoph M. Becker]

On 17.10.2016 at 23:09, Craig Duncan wrote:

> On 17 October 2016 at 21:57, Nikita Popov  wrote:
>>
>> I'm not sure I understand the motivation for throwing a deprecation notice
>> instead of a warning. In particular, what is the action that will be taken
>> here in the next major version? I guess we would throw a warning and return
>> false (instead of 0/1). But is the change of return value from 0/1 to false
>> really sufficiently worthwhile to go with a deprecation first?
>
> I don't feel strongly either way, as long as there's some clue that
> something's not right.
> 
> Is there precedent for adding warnings in a minor? Would there be BC
> concerns there?

 is
supposed to introduce a new E_WARNING in PHP 7.2.

And yes, there is a (small) BC break, but even E_DEPRECATED might be
regarded as such.

> I wouldn't want an RFC for a warning to fail when people would have voted
> for a deprecation.

You might consider offering this as voting option.

>> In any case, if you want to go with deprecation, please specify what
>> action this RFC implies for PHP 8.
>
> Would it be acceptable for the RFC to state that this has no implications
> for PHP 8, and is an indefinite deprecation?

In my opinion, an indefinite deprecation doesn't make much sense.

-- 
Christoph M. Becker


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

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Lester Caine]

On 18/10/16 12:37, Yasuo Ohgaki wrote:
> The patch committed is pure bug fix.
https://www.google.co.uk/search?q=%2Fdev%2Furandom+is+not+readable+by+php

Even bug fixes need proper documentation to avoid the WTF !

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Yasuo Ohgaki]

On Tue, Oct 18, 2016 at 8:00 PM, Lester Caine  wrote:
> On 18/10/16 11:02, Niklas Keller wrote:
>>> 'Suppliers' should perhaps be helped to configure their systems so the
>>> > users can use things, but things like /dev/urandom may need some
>>> > additional notes to help identify problems when frameworks like owncloud
>>> > start throwing errors. As Niklas says it's shared environments where
>>> > this one may bite.
>>> >
>> Just to be clear: I don't argue that those systems are broken, I just say
>> that there is a BC break for those systems and that this has to be
>> documented.
>
> Yes ... and the RFC process is at least part of the documentation.

The patch committed is pure bug fix.

uniqid() is simply _broken_ because it does not provide expected uniqueness due
to timestamp based php_combined_lcg(). (I added large warning to the manual
recently, though)

unique id (time stamp) + entropy (timestamp based entropy)

Who argue result is reasonably unique?
Who don't use NTP to adjust system time?

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] header() removes all header of the same name.

[Stephen Reay]

Hi Yasuo,

I agree there are probably a lot using the default, but I think it’s reasonable 
to expect anyone using a header(‘Set-Cookie:..’); call rather than setcookie() 
to be aware of the 2nd argument for header(), so this solution sounds good to 
me.

Cheers

Stephen 

> On 18 Oct 2016, at 18:08, Yasuo Ohgaki  wrote:
> 
> Hi Stephen,
> 
> On Tue, Oct 18, 2016 at 5:54 PM, Stephen Reay  wrote:
>> If the replace flag was fixed, isn’t this then just a case of making sure 
>> userland sets replace to false if they want existing set-cookie headers 
>> retained?
> 
> Yes and no.
> 
> If users use the replace flag correctly, then it will work. However, I
> don't expect users set replace flag correctly. If replace flag's
> default was opposite, it would work better.
> 
>> Removing the ability to write a custom Set-Cookie header introduces a bigger 
>> problem than the current one, IMO.
> 
> OK. Let's just fix the replace flag and document removing 'Set-Cookie'
> header by header() may result in unwanted results.
> 
> Everyone is ok with this?
> 
> 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] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Yasuo Ohgaki]

Hi Joe,

On Tue, Oct 18, 2016 at 7:32 PM, Joe Watkins  wrote:
>> This change should go through the standard RFC process and should be
>> targeted at 7.2+ (master) *only*.
>
>> Please check with the RMs before merging functionality changes into
>> release
>> branches. All functionality changes need consent and consensus. Bug fixes
>> (that don't change functionality or break BC) do not.
>
> You were told very specifically that the kinds of changes you proposed here
> require an RFC.

This comment is for original proposal that _changes_ output format, isn't it?

It simply switches entropy source which we already relied on.

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] header() removes all header of the same name.

[Yasuo Ohgaki]

Hi Stephen,

On Tue, Oct 18, 2016 at 5:54 PM, Stephen Reay  wrote:
> If the replace flag was fixed, isn’t this then just a case of making sure 
> userland sets replace to false if they want existing set-cookie headers 
> retained?

Yes and no.

If users use the replace flag correctly, then it will work. However, I
don't expect users set replace flag correctly. If replace flag's
default was opposite, it would work better.

> Removing the ability to write a custom Set-Cookie header introduces a bigger 
> problem than the current one, IMO.

OK. Let's just fix the replace flag and document removing 'Set-Cookie'
header by header() may result in unwanted results.

Everyone is ok with this?

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] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Lester Caine]

On 18/10/16 11:02, Niklas Keller wrote:
>> 'Suppliers' should perhaps be helped to configure their systems so the
>> > users can use things, but things like /dev/urandom may need some
>> > additional notes to help identify problems when frameworks like owncloud
>> > start throwing errors. As Niklas says it's shared environments where
>> > this one may bite.
>> >
> Just to be clear: I don't argue that those systems are broken, I just say
> that there is a BC break for those systems and that this has to be
> documented.

Yes ... and the RFC process is at least part of the documentation.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Re: lxr.php.net is coming soon.... finally....

[Christoph M. Becker]

On 18.10.2016 at 09:07, Ferenc Kovacs wrote:

> the initial setup is done, let me know what did I miss.

Thanks, Ferenc.  It seems that the navigation to symbols in another file
is broken.  Consider, for instance,
.  Clicking on
php_info_print_table_row gives

| Error: File not found!
|
| The requested resource is not available

That also happens for all other identifiers located in other files that
I tried.  Don't know what's wrong there.

-- 
Christoph M. Becker

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

Re: [PHP-DEV] Re: lxr.php.net is coming soon.... finally....

[Joe Watkins]

Morning Ferenc,

   Thanks for taking the time to do that, mucho appreciated(o).

   PECL extensions are missing.

   We used to have hhvm, and other implementations too ... at least hhvm is
nice for reference, not bothered about the others.

   I think that's all ...

Cheers
Joe

On Tue, Oct 18, 2016 at 8:07 AM, Ferenc Kovacs  wrote:

> 2016. okt. 17. 13:49 ezt írta ("Joe Watkins" ):
> >
> > Morning Ferenc,
> >
> > I would love lxr back, Adam has a setup in the mean time, but I'm
> sure he would not like everyone using it.
> >
> > More words of encouragement here ...
> >
> > Cheers
> > Joe
> >
> > On Sat, Oct 15, 2016 at 3:49 PM, Ferenc Kovacs  wrote:
> >>
> >> On Sat, Oct 15, 2016 at 12:36 PM, Christoph M. Becker <
> cmbecke...@gmx.de>
> >> wrote:
> >>
> >> > On 15.10.2016 at 01:10, Yasuo Ohgaki wrote:
> >> >
> >> > > Hi all,
> >> > >
> >> > > LXR is very useful, but the site is down for a long time.
> >> > >
> >> > > http://lxr.php.net/
> >> > >
> >> > > Is this going to be fixed or it will be gone forever?
> >> >
> >> > See .  It appears Dan could
> need
> >> > some help there. :-)
> >> >
> >> > --
> >> > Christoph M. Becker
> >> >
> >> >
> >> > --
> >> > PHP Internals - PHP Runtime Development Mailing List
> >> > To unsubscribe, visit: http://www.php.net/unsub.php
> >> >
> >> >
> >> hi,
> >>
> >> I've got access to the new box and promised to set up opengrok but did
> not
> >> had the time to do it yet.
> >>
> >> --
> >> Ferenc Kovács
> >> @Tyr43l - http://tyrael.hu
> >
> >
>
> hi,
> the initial setup is done, let me know what did I miss.
>

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Joe Watkins]

Morning,

> This change should go through the standard RFC process and should be
> targeted at 7.2+ (master) *only*.

> Please check with the RMs before merging functionality changes into
release
> branches. All functionality changes need consent and consensus. Bug fixes
> (that don't change functionality or break BC) do not.

You were told very specifically that the kinds of changes you proposed here
require an RFC.

You chose to ignore that, and merge an implementation into frozen branches
of PHP.

I have reverted this change.

Do not do that again.

Cheers
Joe

On Tue, Oct 18, 2016 at 8:35 AM, Yasuo Ohgaki  wrote:

> On Tue, Oct 18, 2016 at 4:16 PM, Niklas Keller  wrote:
> > Yasuo Ohgaki  schrieb am Di., 18. Okt. 2016, 08:47:
> >>
> >> Hi Niklas,
> >>
> >> On Tue, Oct 18, 2016 at 3:36 PM, Niklas Keller  wrote:
> >> > Yasuo Ohgaki  schrieb am Di., 18. Okt. 2016,
> 02:21:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> I committed this patch that simply use php_random_bytes() w/o any BC.
> >> >
> >> >
> >> > Doesn't this throw now in some environments where /dev/urandom isn't
> >> > readable?
> >>
> >> It could happen, but such system should not be used now a days.
> >
> >
> > Sure, but it did happen that shared hosts block it, noticed during
> > random_compat adoption.
> >
> > You claimed there isn't any BC break.
>
> The line should be
>
> "There is no BC for usable systems"
>
> Any file permission could disturb PHP script execution, couldn't it?
>
> I think it's nothing special for /dev/urandom. User should set up system
> correctly to use PHP. Then there is no BC at all.
>
> 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] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Niklas Keller]

Lester Caine  schrieb am Di., 18. Okt. 2016, 11:42:

> On 18/10/16 08:35, Yasuo Ohgaki wrote:
> >> Sure, but it did happen that shared hosts block it, noticed during
> >> > random_compat adoption.
> >> >
> >> > You claimed there isn't any BC break.
> > The line should be
> >
> > "There is no BC for usable systems"
> >
> > Any file permission could disturb PHP script execution, couldn't it?
> >
> > I think it's nothing special for /dev/urandom. User should set up system
> > correctly to use PHP. Then there is no BC at all.
>
> 'Suppliers' should perhaps be helped to configure their systems so the
> users can use things, but things like /dev/urandom may need some
> additional notes to help identify problems when frameworks like owncloud
> start throwing errors. As Niklas says it's shared environments where
> this one may bite.
>

Just to be clear: I don't argue that those systems are broken, I just say
that there is a BC break for those systems and that this has to be
documented.

Regards, Niklas

--
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Lester Caine]

On 18/10/16 08:35, Yasuo Ohgaki wrote:
>> Sure, but it did happen that shared hosts block it, noticed during
>> > random_compat adoption.
>> >
>> > You claimed there isn't any BC break.
> The line should be
> 
> "There is no BC for usable systems"
> 
> Any file permission could disturb PHP script execution, couldn't it?
> 
> I think it's nothing special for /dev/urandom. User should set up system
> correctly to use PHP. Then there is no BC at all.

'Suppliers' should perhaps be helped to configure their systems so the
users can use things, but things like /dev/urandom may need some
additional notes to help identify problems when frameworks like owncloud
start throwing errors. As Niklas says it's shared environments where
this one may bite.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] header() removes all header of the same name.

[Stephen Reay]

(Apologies for the dupe, re-sending for the list.)

If the replace flag was fixed, isn’t this then just a case of making sure 
userland sets replace to false if they want existing set-cookie headers 
retained?

Removing the ability to write a custom Set-Cookie header introduces a bigger 
problem than the current one, IMO.

> On 18 Oct 2016, at 14:31, Yasuo Ohgaki  wrote:
> 
> Hi all,
> 
> I understand why header() is made to remove all headers of the same
> name. This is needed in some cases, but it does not work well for some
> cases.
> 
> We need to decide what to do with
> https://bugs.php.net/bug.php?id=72997
> 
> There is 2 issues.
> - header() removes all headers of the same name including 'Set-Cookie'
> - header() ignores replace flag. (This one is easy to fix)
> 
> Since header() enables 'replace flag' by default, it removes all
> 'Set-Cookie' headers sent previously by default. It can easily disturb
> security related cookies to work. i.e. Session ID cookie, Auto Login
> cookie. This bug would be very hard to find for normal users, too.
> 
> Restoring older behavior (Removing only one header) cannot be a
> resolution because it can still disturb security related cookies.
> 
> Possible resolutions:
> 
> - Prohibit 'Set-Cookie' for header() and force users to use setcookie()
> - Mitigate by disabling replace flag by default. (This is not a good idea, 
> IMO)
> 
> Both resolution requires BC, but this is better to be fixed ASAP.
> 
> Non-BC resolution could be:
> - "Ask users to use setcookie() always for 'Set-Cookie'".
> 
> I would like to prohibit 'Set-Cookie' by header() because it may
> remove session ID cookie as well as auto login cookie, etc. If we
> leave released version as it is now, I would like to prohibit
> 'Set-Cookie' by header() in PHP 7.1.
> 
> Problem with this may be that user cannot modify 'Set-Cookie' header
> line as user want.
> 
> $ php -r 'setcookie("REMEMBERME=value; expires=Sat, 03-Sep-2020
> 05:38:43 GMT; path=/; domain=aaa");'
> PHP Warning:  Cookie names cannot contain any of the following '=,;
> \t\r\n\013\014' in Command line code on line 1
> 
> 
> Comments?
> 
> Regards,
> 
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
> 
> -- 
> 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

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

[Nikita Popov]

On Tue, Oct 18, 2016 at 3:35 AM, Sara Golemon  wrote:

> As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.
>
> https://wiki.php.net/rfc/openssl.bignum
>

Why do we need this when we already have GMP?

If the only reason is "not all environments install GMP" then I'm -1 on
this.

Nikita

Re: [PHP-DEV] Re: lxr.php.net is coming soon.... finally....

[Yasuo Ohgaki]

On Tue, Oct 18, 2016 at 4:07 PM, Ferenc Kovacs  wrote:
> hi,
> the initial setup is done, let me know what did I miss.

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] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Yasuo Ohgaki]

On Tue, Oct 18, 2016 at 4:16 PM, Niklas Keller  wrote:
> Yasuo Ohgaki  schrieb am Di., 18. Okt. 2016, 08:47:
>>
>> Hi Niklas,
>>
>> On Tue, Oct 18, 2016 at 3:36 PM, Niklas Keller  wrote:
>> > Yasuo Ohgaki  schrieb am Di., 18. Okt. 2016, 02:21:
>> >>
>> >> Hi all,
>> >>
>> >> I committed this patch that simply use php_random_bytes() w/o any BC.
>> >
>> >
>> > Doesn't this throw now in some environments where /dev/urandom isn't
>> > readable?
>>
>> It could happen, but such system should not be used now a days.
>
>
> Sure, but it did happen that shared hosts block it, noticed during
> random_compat adoption.
>
> You claimed there isn't any BC break.

The line should be

"There is no BC for usable systems"

Any file permission could disturb PHP script execution, couldn't it?

I think it's nothing special for /dev/urandom. User should set up system
correctly to use PHP. Then there is no BC at all.

Regards,

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

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

[PHP-DEV] header() removes all header of the same name.

[Yasuo Ohgaki]

Hi all,

I understand why header() is made to remove all headers of the same
name. This is needed in some cases, but it does not work well for some
cases.

We need to decide what to do with
https://bugs.php.net/bug.php?id=72997

There is 2 issues.
  - header() removes all headers of the same name including 'Set-Cookie'
  - header() ignores replace flag. (This one is easy to fix)

Since header() enables 'replace flag' by default, it removes all
'Set-Cookie' headers sent previously by default. It can easily disturb
security related cookies to work. i.e. Session ID cookie, Auto Login
cookie. This bug would be very hard to find for normal users, too.

Restoring older behavior (Removing only one header) cannot be a
resolution because it can still disturb security related cookies.

Possible resolutions:

 - Prohibit 'Set-Cookie' for header() and force users to use setcookie()
 - Mitigate by disabling replace flag by default. (This is not a good idea, IMO)

Both resolution requires BC, but this is better to be fixed ASAP.

Non-BC resolution could be:
  - "Ask users to use setcookie() always for 'Set-Cookie'".

I would like to prohibit 'Set-Cookie' by header() because it may
remove session ID cookie as well as auto login cookie, etc. If we
leave released version as it is now, I would like to prohibit
'Set-Cookie' by header() in PHP 7.1.

Problem with this may be that user cannot modify 'Set-Cookie' header
line as user want.

$ php -r 'setcookie("REMEMBERME=value; expires=Sat, 03-Sep-2020
05:38:43 GMT; path=/; domain=aaa");'
PHP Warning:  Cookie names cannot contain any of the following '=,;
\t\r\n\013\014' in Command line code on line 1


Comments?

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] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Niklas Keller]

Yasuo Ohgaki  schrieb am Di., 18. Okt. 2016, 08:47:

> Hi Niklas,
>
> On Tue, Oct 18, 2016 at 3:36 PM, Niklas Keller  wrote:
> > Yasuo Ohgaki  schrieb am Di., 18. Okt. 2016, 02:21:
> >>
> >> Hi all,
> >>
> >> I committed this patch that simply use php_random_bytes() w/o any BC.
> >
> >
> > Doesn't this throw now in some environments where /dev/urandom isn't
> > readable?
>
> It could happen, but such system should not be used now a days.
>

Sure, but it did happen that shared hosts block it, noticed during
random_compat adoption.

You claimed there isn't any BC break.

Regards, Niklas

Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] Re: lxr.php.net is coming soon.... finally....

[Ferenc Kovacs]

2016. okt. 17. 13:49 ezt írta ("Joe Watkins" ):
>
> Morning Ferenc,
>
> I would love lxr back, Adam has a setup in the mean time, but I'm
sure he would not like everyone using it.
>
> More words of encouragement here ...
>
> Cheers
> Joe
>
> On Sat, Oct 15, 2016 at 3:49 PM, Ferenc Kovacs  wrote:
>>
>> On Sat, Oct 15, 2016 at 12:36 PM, Christoph M. Becker 
>> wrote:
>>
>> > On 15.10.2016 at 01:10, Yasuo Ohgaki wrote:
>> >
>> > > Hi all,
>> > >
>> > > LXR is very useful, but the site is down for a long time.
>> > >
>> > > http://lxr.php.net/
>> > >
>> > > Is this going to be fixed or it will be gone forever?
>> >
>> > See .  It appears Dan could need
>> > some help there. :-)
>> >
>> > --
>> > Christoph M. Becker
>> >
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>> hi,
>>
>> I've got access to the new box and promised to set up opengrok but did
not
>> had the time to do it yet.
>>
>> --
>> Ferenc Kovács
>> @Tyr43l - http://tyrael.hu
>
>

hi,
the initial setup is done, let me know what did I miss.

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Yasuo Ohgaki]

Hi Niklas,

On Tue, Oct 18, 2016 at 3:36 PM, Niklas Keller  wrote:
> Yasuo Ohgaki  schrieb am Di., 18. Okt. 2016, 02:21:
>>
>> Hi all,
>>
>> I committed this patch that simply use php_random_bytes() w/o any BC.
>
>
> Doesn't this throw now in some environments where /dev/urandom isn't
> readable?

It could happen, but such system should not be used now a days.

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] OpenSSL BigNum support

[Sara Golemon]

On Mon, Oct 17, 2016 at 11:41 PM, Sebastian Bergmann  wrote:
> Am 18.10.2016 um 08:23 schrieb Sara Golemon:
>> I'm mostly curious about thoughts on API decisions.
>
> * public static function createFromBinary(string $number): BigNum;
> * public static function createFromInteger(int $number): BigNum;
> * public static function createFromString(string $number): BigNum;
>
I did consider that (though with a required base parameter for
createFromString() (which, due to OpenSSL's API would be constrained
to 10 or 16).

-Sara

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

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

[Sebastian Bergmann]

Am 18.10.2016 um 08:23 schrieb Sara Golemon:
> I'm mostly curious about thoughts on API decisions.

Can we make the constructor non-public and instead only have named
constructors?

* public static function createFromBinary(string $number): BigNum;
* public static function createFromInteger(int $number): BigNum;
* public static function createFromString(string $number): BigNum;


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

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Niklas Keller]

Yasuo Ohgaki  schrieb am Di., 18. Okt. 2016, 02:21:

> Hi all,
>
> I committed this patch that simply use php_random_bytes() w/o any BC.
>

Doesn't this throw now in some environments where /dev/urandom isn't
readable?

Regards, Niklas

http://git.php.net/?p=php-src.git;a=commitdiff;h=48f1a17886d874dc90867c669481804de90509e8
>
> I thought there is php_random_int(), but it's not.
> So this is one of the best patch for this purpose.
>
> There is bug reports that request stronger uniqueness by default.
> I may address this issue, but I would like to fix other things for the
> time being.
>
> Regards,
>
> --
> Yasuo Ohgaki
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

[Sara Golemon]

> Looks ok to me. Would probably not hurt also add tests for various error
> conditions.
>
There's one TypeError test in there, but I can easily add more. (And
probably will on my flight tomorrow.)

> I realise this is only exposing functionality already available with
> OpenSSL but is it worth adding tests that cover some arbitrary precision
> arithmetic? The tests at the moment cover integers that PHP already
> handles natively without requiring either GMP or BCMath.
>
This type of test is certainly worth including.  I'll add some it these as well.

I'm mostly curious about thoughts on API decisions.  For example: Do
we want this in a namespace? Would we rather match GMP's function
based API for consistency? I like the decisions I made, but I can
imagine disagreement.

-Sara

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