Re: [PHP-DEV] What's up with github.com/php-src?

[Leigh]

On Sat, 9 Feb 2019 at 14:33 Derick Rethans  wrote:

> On Sat, 9 Feb 2019, Ben Ramsey wrote:
>
> >
> > > On Feb 8, 2019, at 22:46, Bishop Bettini  wrote:
> > >
> > > Having mistakenly cloned php-src/php <https://github.com/php-src/php>
> > > instead of php/php-src <https://github.com/php/php-src> (again), I
> figured
> > > I'd ask -- is php-src used for anything?
> > >
> > > The code seems to be quite old, and the content of php-src/
> php-src.github.io
> > > <https://github.com/php-src/php-src.github.io> is a music video.
> Neither
> > > seems productive to the PHP community.
> > >
> > > Am I missing something?
> >
> >
> > My guess is that someone set up the php-src GitHub organization to
> > troll people, since the Rebecca Black “Friday” music video is clearly
> > a kind of rickroll. :-)
>

Indeed. It was meant as a joke, not to deceive anyone. I'll take it down :)


>
> That commit was done by Leigh , which was active on
> internals in 2016. Perhaps we should ask them to remove it?
>
> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.1.0 to 7.2.0beta2 mt_rand() modulo bias bug

[Leigh]

On Wed, 16 Aug 2017 at 20:13 Solar Designer  wrote:

> Also, why even bother to support ranges beyond 32-bit?  Sounds like a
> misfeature to me, considering it won't(?) be universally available on
> all PHP builds anyway (not on 32-bit ones, right?) and thus shouldn't(?)
> be relied upon by applications (although it might become reasonable for
> application developers not to care about 32-bit soon).  I also see few
> use cases for it, even if it were universally available.
>

It was possible (on 64 bit builds) to specify min and max such that the
size of the output required from mt_rand was the full 64 bit range.

Prior to 7.1 this full output was created by stretching a single 32 bit
output up to the required range using floating point arithmetic, which
caused other biases in the output.

Unfortunately when fixing this bias, a new bias was introduced. I took
known working code from the CSPRNG and didn't account for the variable
length of the sample.

My proposed fix would be to add a "limit_max" variable, initialise it to
UINT32_MAX, and in the first range check where we decide to add an extra
output or not, set it to ZEND_ULONG_MAX. Then the statement creating the
ceiling value can use limit_max instead of the constant value.

Re: [PHP-DEV] Re: Improving mt_rand() seed

[Leigh]

On 27 January 2017 at 14:30, Lauri Kenttä  wrote:
>> This needs to be thought of as 2^32 possible _streams_ with a period
>> of (2^19937)−1. Offset within the stream is as important as the stream
>> variation itself.
>
> This is not true. There is one stream of period (2^19937)−1, and
> the initial state defines the current position in that stream.

I'm not sure about this, the LCG constant used in the initial
generator seems completely unrelated to the rest of the algorithm, so
I don't see how this offsets the stream position.

If it is truly the case, I stand corrected.

>> Even with 2^32 possible initial states every
>> password generated will still have a bit strength of 2^60
>
>
> If the attacker knows the algorithm, the bit strength is only 2^32.
> The remaining 2^28 comes from security through obscurity, which is
> not a generally valid real security thing.

Fair point.

> Anyway, a password should be better generated with CSPRNG, not MT,
> so "hardening" MT is totally irrelevant.

Obviously.

I still maintain that pulling 2.5k from the CSPRNG to power MT is
overkill though. I agree we shouldn't waste time "hardening" it just
because some people misuse it. We can make the initial seeding less
deterministic but I don't think we should do more than that.

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

Re: [PHP-DEV] Re: Improving mt_rand() seed

[Leigh]

On 27 January 2017 at 02:52, Yasuo Ohgaki  wrote:
> Since mt_rand is predictable PRNG, there is possibility to be known to
> attackers always.
>
> What I would like to change is
>
>  - there is only 2^32 initial states

This needs to be thought of as 2^32 possible _streams_ with a period
of (2^19937)−1. Offset within the stream is as important as the stream
variation itself.

> Think of a code that generates "random password string" from mt_rand.
> (We know nobody should do this, but there are many codes do this)
>
> If password is alpha numeric+#$ and 10 chars long, there could be
>  64^10 = 2^60 patterns with pure random.

Statistical testing of MT shows it to be pretty good. The ability to
recover the state from full outputs doesn't subtract from the quality
of the randomness. It is absolutely not a cryptographic quality
generator, but it is a high quality source of entropy.

In fact state recovery is made harder in PHP because we only ever emit
31 of the 32 bits of output. This compounds over 624 outputs, and
while it doesn't make it impossible to recover it adds some difficulty
(especially when you don't know when the state will twist).

Another factor to consider is that people discard _most_ of the output
when they do things like using mt_rand to generate character strings,
so an observer only sees 8 out of 32 bits per call, making state
recovery exceptionally more difficult (again not knowing when the
state will be mutated).

> but with current mt_rand could generate only
>  2^32 patterns due to mt_rand() limited state.

The 2^32 vs 2^60 is a false equivalence. 2^32 is the theoretical
number of unique passwords that can be generated from a freshly
initialised state, while 2^60 represents the "bit strength" of a
_single_ password. Even with 2^32 possible initial states every
password generated will still have a bit strength of 2^60

> This is a lot less random than it could be.
>
> Hardening mt_rand() w/o salt value beneficial to general mt_rand() usage
> also.
> i.e. PHP app runs short periods of time and only use beginning of MT rand
> cycle.
> More than 99% random cycle is wasted currently.

You can force this kind of scenario if you have for example a CLI
script that generates a single password and then exits. In this case
you only have 2^32 possible unique outcomes, but this is rarely the
case.

The MT state is per-process, not per request. If you do not explicitly
re-seed it then you will continue down that 2^19937 period. So in fact
it is far safer to not re-seed MT explicitly from user-land code.

In most applications you cannot guarantee that your request is being
served by the same process, you will never get a full outputs, and you
never know your position within the state. State recovery is generally
going to be infeasible, even right now without any changes.

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

Re: [PHP-DEV] Re: Improving mt_rand() seed

[Leigh]

On Sat, 21 Jan 2017 at 14:41 Niklas Keller  wrote:

> Anyway, the "issue" with mt_rand is not the seed being predictable but the
> internal state being recoverable from the output. But mt_rand is
> predictable by design, so why should we even seed it with a CSPRNG by
> default?
>
>
> For the record, when I was making RNG changes for 7.1, I did look at the
mt_rand seed mechanism, and decided it was _good enough_ for the purposes
of mt_rand.

State recovery can actually be done with as few as 624 sequential outputs,
you will never be able to get away from that. Even with a fully CSPRNG
generated state, if an attacker gets 624 outputs after the state is
twisted, the RNG is compromised.

Re: [PHP-DEV] Re: Improving mt_rand() seed

[Leigh]

On 19 January 2017 at 11:46, Yasuo Ohgaki  wrote:
> How many of us are willing to allow very weak mt_rand fallback?
> This could be RFC vote option, if there are few.

Everyone who cares about stability.

I agree, if you want to introduce breaking changes, this needs to go to RFC.

Therefore the simplest option seems to be DON'T introduce breaking
changes. Wouldn't you agree?

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

Re: [PHP-DEV] Re: Improving mt_rand() seed

[Leigh]

On 19 January 2017 at 01:10, Yasuo Ohgaki  wrote:
>
> Thank you. I have to be able to modify patch, so I'll fetch your change to
> my repo
> and make PR. BTW, I don't think we have to care for failing CSPRNG. If it
> failed,
> application should fail properly, i.e. should terminate process/code.
> PHP apps are not OS nor DBMS, they have freedom to terminate/exit when fatal
> event happened.
>

You _do_ have to care if it fails. This is a breaking change if it is
not handled. mt_rand is _not_ a CSPRNG, and therefore the absence of a
CSPRNG should not make mt_rand unusable.

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

Re: [PHP-DEV] Re: Improving mt_rand() seed

[Leigh]

On 18 January 2017 at 16:06, Lauri Kenttä  wrote:
>
> If it's not acceptable to randomize the whole state, I'd recommend using
> php_random_int_silent() to generate a single seed. This would be easy to
> implement by simply changing GENERATE_SEED() into a function which first
> tries php_random_int_silent() but has the current method as a fallback. This
> would fix other use cases of GENERATE_SEED() as well.

You don't need to use the random_int functions, 4 bytes from
php_random_bytes_silent cast into a uint32_t will give you an unbiased
seed. (powers of 2 are unbiased)

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

Re: [PHP-DEV] Re: Improving mt_rand() seed

[Leigh]

On Wed, 18 Jan 2017 at 06:05 Yasuo Ohgaki  wrote:

> It could be. I haven't read and research MT rand initialization code
> carefully yet.


I have, it stretches 4 bytes of seed material into 624 * 4 bytes of
material. There are only 2^32 possible initial states from direct seeding.

After the state has been consumed it does a "twist"-pass on the existing
state, this is where the "^19937-1 period comes from.

I would recommend taking 4 bytes from php_random_bytes_silent() cast to
uint32_t and passed to php_mt_srand(), if php_random_bytes_silent() fails
fall back to the original seeding generation mechanism (it is unlikely an
adversary can know which method was used)

Re: [PHP-DEV] [RFC][Vote] HashContext using Objects

[Leigh]

On Tue, 17 Jan 2017 at 22:49 Sara Golemon  wrote:

> Voting has opened on: https://wiki.php.net/rfc/hash-context.as-resource
>
> Voting will remain open for two weeks and will close on 31 Jan, 2017
> at 23:59:59 UTC
>
> -Sara
>

Thanks for the work on this.

I've voted for frozen behaviour because I feel like the continued use of a
context is more likely to be a bug than intentional behaviour.

It's also more in-line with crypto code I'm familiar with, a finalised
context is finalised.

Re: [PHP-DEV] Improving mt_rand() seed

[Leigh]

On 16 January 2017 at 07:04, Yasuo Ohgaki  wrote:
> Hi all,
>
> Since I was about to improve uniqid()'s entropy by replacing
> php_combined_lcg() to php_random_int(), I spent time to check other places
> that could be a problem.
>
> mt_rand()'s is seeded as follows by default.
>
> ext/standard/php_rand.h
> #ifdef PHP_WIN32
> #define GENERATE_SEED() (((zend_long) (time(0) * GetCurrentProcessId())) ^
> ((zend_long) (100.0 * php_combined_lcg(
> #else
> #define GENERATE_SEED() (((zend_long) (time(0) * getpid())) ^ ((zend_long)
> (100.0 * php_combined_lcg(
> #endif
>
> We know this kind of seed is guessable. i.e. Our session id is compromised
> by this kind of code.

mt_rand is not advertised as crypto-quality.

Where do you think mt_rand is used in session id generation?

>
> Although it would be rare that raw mt_rand() value is exposed, but
> guessable value is guessable. I'm going to replace the seeding code by
> simple php_random_int() call.
>
> 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] Fwd: Monotonic Time

[Leigh]

On Fri, 13 Jan 2017 at 09:35 Niklas Keller  wrote:

> Hi Anatol,
>
> Do you think we should merge hrtime into core or add a simple function just
> like microtime() to ext/standard?
>
> Regards, Niklas
>

It would be great if it could be a simple function, however it is going to
be difficult to produce something cross-platform and meaningful with a
single function. (I know Anatol has written portable code, I haven't looked
at it but I assume it's wrapping the various structs used by i.e.
performance counters, hrtime, etc.)

I don't think we can get away from having an object-based implementation to
wrap those internal structs, but I do think this is a useful addition
regardless of how it's presented.

Re: [PHP-DEV] Fw: unpack()

[Leigh]

On 29 February 2016 at 07:43, Dmitry Stogov <dmi...@zend.com> wrote:
> I think the most clear way is to apply the new $offset argument and then the 
> old way to skip first bytes of input string.
> So unpack("@$skip/N4", $message, $offset) will skip $offset+$skip.
> Actually, this is the way  how the proposed patch works.
>
> Thanks. Dmitry.
>
>
> ____
> From: Leigh <lei...@gmail.com>
> Sent: Thursday, February 25, 2016 18:20
> To: Dmitry Stogov
> Cc: Nikita Popov; internals@lists.php.net; Hynek Bartoš
> Subject: Re: [PHP-DEV] Fw: unpack()
>
> On 25 February 2016 at 13:02, Dmitry Stogov <dmi...@zend.com> wrote:
>>
>> I've just got to know about possible usage of "@" in unpack(), but it seems
>> doesn't work at all
>>
>> $ sapi/cli/php -r 'var_dump(unpack("@0l", "\x01\x00\x00\x00")); '
>> array(0) {
>> }
>>
>> Do I use it properly?
>>
>> Thanks. Dmitry.
>>
>
> As Nikita said, you need the "/". I use this operator when processing
> streams of binary data.
>
> Trimmed down example:
>
> while ($blocks--) {
> list(, $x0, $x1, $x2, $x3) = unpack("@$offset/N4", $message);
> //...
> $offset += 16;
> }
>
> The dynamic format string is kind of nasty though, so no objections to
> an additional parameter making things clearer, however, what is to be
> done if an offset is specified in both the format string and the
> additional parameter? Does one override the other? Are they additive?


Hi Dmitry,

I noticed this is half implemented. You have committed some changes to
unpack to cater for the offset argument, but arginfo_unpack was never
updated.

What was the intention with this?

Cheers,

Leigh.

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

[PHP-DEV] Re: [PECL-DEV] Intention to move mcrypt to PECL

[Leigh]

Ok rookie PECL mistake here.

I was adding Derick and Sascha as leads (as they were the original leads)
and demoting myself to helper (not knowing it was required to further
maintain the package). So I have locked myself out :)

Could you add me back as a lead to the pecl package please, so I can upload
the release tarball.

Cheers,

Leigh

On Mon, 12 Dec 2016, 00:52 Ferenc Kovacs, <tyr...@gmail.com> wrote:

>
> On Wed, Oct 19, 2016 at 7:44 PM, Leigh <lei...@gmail.com> wrote:
>
>
> On Wed, 5 Oct 2016 at 20:11 Derick Rethans <der...@php.net> wrote:
>
> It should be migrated properly, and also to GIT.
>
>
> Hi Ferenc,
>
> Can you create a php.net hosted git repository for this (I guess under
> the pecl/security namespace), and grant karma to le...@php.net for it.
>
> Sorry for picking on you personally. I don't know who else can do this :)
>
> Cheers,
>
> Leigh.
>
>
>
>
> Hi,
>
> I've just created the http://git.php.net/?p=pecl/encryption/mcrypt.git
> repository (I think encryption was a better category as we already have
> scrypt, libsodium and mcrypt_filter there).
> Leigh already had karma for pecl/*, let me know if you need help with
> creating the package or importing the source to the repo (
> https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/
> if you want to keep the history).
>
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>

Re: [PHP-DEV] Security issue handling

[Leigh]

On Sat, 5 Nov 2016 at 19:13 Stanislav Malyshev  wrote:

> Hi!
>
> > On 24/10/2016 07:16, Stanislav Malyshev wrote:
> >> c. Get some specific people to volunteer to review patches in security
> >> repo regularly - how? Any takers?
> >
> > I'd be happy to help with reviewing and also setting up a private C.I.
> > to build and run the test suite regularly, if you think that's a good
> idea.
>
> I think it's a great idea, how could this be done? I'd be happy to run
> CI on security branch, it probably would remove 95% of the issues we had
> with merges.
>

Travis can be run in local docker containers, so given the infrastructure
to run the container, it shouldn't be a problem to use the existing travis
configuration for private CI

Re: [PHP-DEV] Security issue handling

[Leigh]

On 24 October 2016 at 06:16, Stanislav Malyshev <smalys...@gmail.com> wrote:
> Hi!
>
> I'd like to discuss an issue about security bugs handling.
>
> We have a security repo which I and others check into bugs from time to
> time. The idea is for these to be reviewed by people having access there
> before we merge them, and then merge after the release.
>
> This, however, is not happening at all. The patches, as far as I know,
> are not reviewed at all, and merging a bunch of patches last minute with
> no review is extremely dangerous. I am trying my best with my patches,
> but I'm only human, and I feel increasingly uncomfortable having so many
> unreviewed patches in the release.
>
> So, how we can fix it?
>
> a. We could merge some of the patches on RC stage, even though that
> might expose some issues.
> b. We could somehow improve review mechanism beyond security repo we
> have now - ideas?
> c. Get some specific people to volunteer to review patches in security
> repo regularly - how? Any takers?
>
> Would like to hear thoughts on this one.
> --
> Stas Malyshev
> smalys...@gmail.com

Hey Stas,

If it's extra volunteers that you need, I would also be happy to help
out where I can, investigating reported issues, writing and reviewing
patches.

* I have a provable interest in security
* I've submitted security issues (to PHP and other projects) in the past
* I have worked on security features for the PHP runtime in the past
* I already have karma \o/

Regards,

Leigh.

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

[PHP-DEV] Strict types indicator in backtraces

[Leigh]

Hi all,

I've written a small patch to add a "strict_types" key to the backtrace
information for functions.

https://github.com/php/php-src/pull/2177

The idea here is to be able to see more easily whether a parameter may have
had it's type changed or not during a trace.

Thoughts and opinions?

Cheers,

Leigh.

[PHP-DEV] Re: [PECL-DEV] Intention to move mcrypt to PECL

[Leigh]

On Wed, 5 Oct 2016 at 20:11 Derick Rethans <der...@php.net> wrote:

> It should be migrated properly, and also to GIT.
>

Hi Ferenc,

Can you create a php.net hosted git repository for this (I guess under the
pecl/security namespace), and grant karma to le...@php.net for it.

Sorry for picking on you personally. I don't know who else can do this :)

Cheers,

Leigh.

Re: [PHP-DEV] [RFC] Counting of non-countable objects

[Leigh]

On 11 October 2016 at 10:49, Craig Duncan  wrote:
> I've updated the RFC now to take the deprecation route, and included
> counting scalars:
>
> https://wiki.php.net/rfc/counting_non_countables
>
> The only remaining issue is what to do about handling *count(null)*
> I think this should be deprecated too, but as it's the only case that
> returns zero I wasn't sure whether other folk felt differently?

I'd agree that count(null) has no real benefit, and is probably an error.

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

Re: [PHP-DEV] Intention to move mcrypt to PECL

[Leigh]

On 6 October 2016 at 13:35, Ferenc Kovacs <tyr...@gmail.com> wrote:
>
>
> On Thu, Oct 6, 2016 at 12:12 PM, Jakub Zelenka <bu...@php.net> wrote:
>>
>> Hi,
>>
>> On Tue, Oct 4, 2016 at 5:58 PM, Leigh <lei...@gmail.com> wrote:
>>
>> > Hello list,
>> >
>> > It is my intention to create a new PECL package for ext/mcrypt, so
>> > that it can be removed from master as per the RFC
>> > (https://wiki.php.net/rfc/mcrypt-viking-funeral)
>> >
>> > I do not expect there to be any updates to the extension after it has
>> > been migrated, however we voted to move it there.
>> >
>> > Any objections/comments? If not I'll apply for my PECL account in the
>> > next few days.
>> >
>> >
>> I don't think it can be added to PECL as it breaks its licensing rules
>> (mcrypt is GPL licensed):
>>
>>
>>- Note: wrappers for GPL (all versions) or LGPLv3 libraries will not be
>>accepted. Wrappers for libraries licensed under LGPLv2 are however
>> allowed
>>while being discouraged.
>>
>> See https://pecl.php.net/account-request.php
>>
>> Cheers
>>
>> Jakub
>
>
> AFAIK mcrypt is gpl, libmcrypt (wrapped by our mcrypt ext) is lgpl so it
> would be fine for pecl.
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu

http://mcrypt.cvs.sourceforge.net/viewvc/mcrypt/libmcrypt/COPYING.LIB?revision=1.1.1.1=markup

LGPLv2

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

Re: [PHP-DEV] Intention to move mcrypt to PECL

[Leigh]

On 6 October 2016 at 11:12, Jakub Zelenka <bu...@php.net> wrote:
> Hi,
>
> On Tue, Oct 4, 2016 at 5:58 PM, Leigh <lei...@gmail.com> wrote:
>>
>> Hello list,
>>
>> It is my intention to create a new PECL package for ext/mcrypt, so
>> that it can be removed from master as per the RFC
>> (https://wiki.php.net/rfc/mcrypt-viking-funeral)
>>
>> I do not expect there to be any updates to the extension after it has
>> been migrated, however we voted to move it there.
>>
>> Any objections/comments? If not I'll apply for my PECL account in the
>> next few days.
>>
>
> I don't think it can be added to PECL as it breaks its licensing rules
> (mcrypt is GPL licensed):
>
> Note: wrappers for GPL (all versions) or LGPLv3 libraries will not be
> accepted. Wrappers for libraries licensed under LGPLv2 are however allowed
> while being discouraged.
>
> See https://pecl.php.net/account-request.php
>
> Cheers
>
> Jakub
>

Interesting, thanks for that.

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

[PHP-DEV] Re: [PECL-DEV] Intention to move mcrypt to PECL

[Leigh]

On 5 October 2016 at 20:11, Derick Rethans  wrote:
> It should be migrated properly, and also to GIT. I prefer that it is
> released with my username as "lead", as I wrote a big deal of it.
>
> cheers,
> Derick

I'm not sure what you mean by "properly", what steps do you think I'll
miss out? (My intention was always to ask for a php.net git repo for
it)

Of course you (and Sascha) should be listed as lead (I'll leave the
"active" flags up to you - not sure if this is supposed to mean in
general, or on the extension itself), I have little interest in
maintaining this extension myself.

My motivation is to remove it from master as soon as possible, so
those testing or experimenting with future releases get an early
indication of what is coming, rather than it happening at 7.2 beta and
people only getting a couple of months. However the RFC said remove
and move to PECL, so I am trying to follow what we agreed on, and get
it moved to PECL prior to deleting it from master.

Would you like to handle this migration yourself?

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

[Leigh]

The list was missed off of Yasuo's replies to me, replying including the
list

On Wed, 5 Oct 2016 at 01:07 Yasuo Ohgaki <yohg...@ohgaki.net> wrote:

> Hi Leigh,
>
> On Tue, Oct 4, 2016 at 7:06 PM, Leigh <lei...@gmail.com> wrote:
> > Since we want to preserve BC
> >
> > entropy = random_int(0, );
> > uniqid = strpprintf(0, "%s%08x%05x.%08d", prefix, sec, usec, entropy);
>
> Current entropy is _double_ from php_combined_lcg() and has 10 chars
> length,
> has [0-9].[0-9]{8} format.
>
> "F"->"d" does not work. It should be something like
>
> entropy = (double) random_int(0, 99);
>

No it shouldn't. Don't do this. It is an unnecessary conversion. The fact
the lcg returns a double is irrelevant. What is relevant is the 8 digits in
order to maintain BC. The 8 digits you receive from random_int will still
be higher quality than the 10 you get from the lcg rounded to 8 places.


> uniqid = strpprintf(0, "%s%08x%05x.%08F", prefix, sec, usec,
> entropy/1);
>




On Wed, 5 Oct 2016 at 01:16 Yasuo Ohgaki <yohg...@ohgaki.net> wrote:

> On Wed, Oct 5, 2016 at 9:06 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> > Current entropy is _double_ from php_combined_lcg() and has 10 chars
> length,
> > has [0-9].[0-9]{8} format.
> >
> > "F"->"d" does not work. It should be something like
> >
> > entropy = (double) random_int(0, 99);
> > uniqid = strpprintf(0, "%s%08x%05x.%08F", prefix, sec, usec,
> entropy/1);
>
> Forgot to mention, this code leak more information about PRNG state
> than my patch because php_random_int() copies random binary data into
> long. It's still part of it and exposure of random data shouldn't
> matter, so this is minor issue.
>

I think there is a misunderstanding here. You're using the CSPRNG which is
designed such that the _entire_ output can be made public without you being
able to predict the next result. That is the definition of a CSPRNG. Also
remember this is "output" not "state".

While researching how to implement these CSPRNG functions, I spoke with
real security experts on the subject, they all said the same thing: Use the
system CSPRNG, and yes, it is fine to expose the output directly.

Also if you really are worried (which you shouldn't be), requesting 8
digits from random_int will effectively discard 5 or 37 bits of output
depending on whether you're on a 32 or 64 bit platform. You cannot know the
value of sequential outputs.


> I'll update gist.
> Any more comments?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net

[PHP-DEV] Intention to move mcrypt to PECL

[Leigh]

Hello list,

It is my intention to create a new PECL package for ext/mcrypt, so
that it can be removed from master as per the RFC
(https://wiki.php.net/rfc/mcrypt-viking-funeral)

I do not expect there to be any updates to the extension after it has
been migrated, however we voted to move it there.

Any objections/comments? If not I'll apply for my PECL account in the
next few days.

Cheers,

Leigh.

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

[Leigh]

On 4 October 2016 at 10:32, Craig Duncan  wrote:
> Hi everybody
>
> I'd like to propose the introduction of warning when counting objects that
> can't be counted.
>
> The default behaviour is to return 1 for these objects, which can be
> misleading and hide bugs when attempting to count iterable objects (eg
> Generators). Adding a warning would alert developers to the issue
>
> https://wiki.php.net/rfc/counting_non_countables
>
> Thanks,
> Craig

I like this. I would personally like to see this behaviour deprecated
and removed in 8.0

You specifically mention that counting scalars is unaffected, is there
a legitimate use-case for being able to use count() on them?

I'd say using count() on a string or an int also constitutes a hidden
bug, as it also always returns 1 regardless of the value.

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

[Leigh]

On 4 October 2016 at 02:39, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi Leigh,
>
> On Mon, Oct 3, 2016 at 9:06 PM, Leigh <lei...@gmail.com> wrote:
>> I'm curious, did you consider using random_int? It already handles
>> biasing, and you can reduce the repeated calls to random_bytes.
>
> Yes. It seemed it might be slower due to number of retries at first,
> but I realized that it isn't later.
>
> It could be something like
>
> $entropy = random_int(100, 99);
> $entropy[1] = '.';
> $uniqid = timestamp . $entropy;
>
> I don't have particular preference.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net

Since we want to preserve BC

entropy = random_int(0, );
uniqid = strpprintf(0, "%s%08x%05x.%08d", prefix, sec, usec, entropy);

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

[Leigh]

On 2 October 2016 at 21:03, Yasuo Ohgaki  wrote:
> Hi all,
>
> On Mon, Oct 3, 2016 at 3:56 AM, Yasuo Ohgaki  wrote:
>> Besides improving "more entropy" the default and data, I prepared
>> fully compatible patch to simplify discussion.
>>
>> https://gist.github.com/anonymous/fb615df325d559fa806a265031a06ede
>>
>> I would like to apply this patch from PHP 7.0 branch, then discuss what
>> the default should be.
>>
>> Any comments?
>> If there is no objections, I'll apply this few days later.
>
> Updated patch a little
>
> https://gist.github.com/yohgaki/cbe5431f9d072b57af2883a2b5745195
>
> Exception should not be ignored, but added few lines for this.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

I'm curious, did you consider using random_int? It already handles
biasing, and you can reduce the repeated calls to random_bytes.

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

Re: [PHP-DEV] [VOTE] get_class() disallow null parameter

[Leigh]

On Sun, 25 Sep 2016 at 06:29 Pierre Joye  wrote:

> Also this behavior is clearly documented:
>
> http://th1.php.net/manual/en/function.get-class.php
>
> "If object is omitted when inside a class, the name of that class is
> returned."
>
> I am opposed to break BC because we change our mind about how clean is this
> behavior and I recommend the (future) RMs to veto this change.
>
> Cheers
> Pierre
>

This is ambiguous at best.

"Omitted" and "Not omitted but set to null" are different things.

I'm +/-0 on the RFC, but I would not agree that the documentation is clear.

Re: [PHP-DEV] Missing reflection info about strict types?

[Leigh]

On Mon, 5 Sep 2016 at 10:39 Nicolas Grekas  wrote:

> Hello,
>
> It looks like we miss a way to check by reflection if a function/method has
> strict types enabled or not.
>
> We'd need to do this in Symfony to generate a file with concatenated
> classes, but split "declare_strict=1" classes out so that they don't break
> (because there is no way to create a single file that contains both strict
> and non-strict classes unfortunately also).
>
> Would it be possible to expose some flavor of ZEND_ACC_STRICT_TYPES to
> userland?
>
> Regards,
> Nicolas
>

As an aside, would you guys like to see a strict types indicator in debug
backtraces? I wrote a small patch for it back during development of 7, and
then forgot about it.

https://github.com/lt/php-src/commit/ac1171a81df814ad0042ef5989010bfe7d3e1652

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Leigh]

On Fri, 2 Sep 2016 at 20:33 Davey Shafik  wrote:

>
> I believe that pickle solves the issues with regards to pecl, and have run
> the idea passed Jordi and Pierre. Both are fine with this RFC. :)
>
> I understand that adding in composer/pickle is just setting us up for
> having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
> I've proposed the voting reflect that some people will just want to
> deprecate/remove pear/pecl and not replace them at all.
>
> I'm also proposing voting choices around the optional/default introduction
> of composer/pickle.


I'm -1 on bundling composer and/or pickle. If people want this software it
is trivial to obtain, and is far easier to keep up to date if it is managed
out of band.

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)

[Leigh]

On 2 September 2016 at 16:18, Davey Shafik  wrote:
> I would still be OK adding this in RC2, TBH. I didn't realize it was missed,
> and it's something we _need_ to do.
>
> - Davey

Actually, my apologies. I appear to have been living in the future and
was expecting mcrypt to have been removed this release. Sorry! :)

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

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)

[Leigh]

On 22 March 2016 at 17:00, Scott Arciszewski  wrote:
> Hi all,
>
> https://wiki.php.net/rfc/mcrypt-viking-funeral
>
> The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6 No. This is a 79.3%
> favorable response, which exceeds the 2/3 majority by a significant margin.
>
> Thanks to everyone who voted or participated in this discussion.
>
> I've heard and respect some of the objections raised by folks who voted No,
> but moving this liability out of the core into PECL as soon as possible is
> not only a good move for the security of PHP applications, but now we know
> it's the choice the community wants.
>
> As promised, I'll get the E_DEPRECATED patch written soon.

As we're now at RC1, I assume it is too late to push forward with this?

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

Re: [PHP-DEV] [RFC][VOTE] Add session_create_id() function

[Leigh]

On Wed, 10 Aug 2016 at 10:15 Yasuo Ohgaki  wrote:

> Hi all,
>
> This is RFC for adding session_create_id() function.
>
> Session ID string uses special binary to string conversion. Users
> should write lengthy and slow code to have the same session ID string
> as session module does.


I disagree, this pretty much covers it:

function session_create_id()
{
$encoded = base64_encode(random_bytes(32));
// Use same charset as PHP
return rtrim(strtr($encoded, '+/', ',-'), '=');
}

[PHP-DEV] Re: BC break with rand() where min > max

[Leigh]

On Wed, 10 Aug 2016 at 14:19 Tom Worster  wrote:

> Your fix seems fine for rand() but less so for mt_rand().
>
> Applying this fix will break much less mt_rand()-using code than not
> applying it will break rand()-using code. From that point of view,
> applying it is the better choice.
>
> Otoh, it's like copy-pasting a weird old bug from rand() to mt_rand().
> The plan was to make rand() alias mt_rand(). Now I'm not sure that's a
> smart plan.
>
> Tom
>

I've pushed a fix that keeps the old behaviour for both

I've un-aliased rand from mt_rand, added a min > max check to rand, and
then call the common code with parameters reversed if necessary.

[PHP-DEV] BC break with rand() where min > max

[Leigh]

Hi all,

There has been an unforeseen break with rand() when the minimum value is
greater than the maximum.

Prior to 7.1 rand() would happily accept backwards parameters and return a
value, however in the 7.1 branch it now emits a warning and returns false.

I've preemptively committed a fix to allow min > max and return a value as
in previous versions, but have kept the warning.

Looking for some feedback/opinions on whether anyone else thinks this
should be fixed differently (or not at all).

N.B. this also changes the behaviour of mt_rand to now accept min > max

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

[Leigh]

On Thu, 7 Jul 2016 at 11:39 Leigh <lei...@gmail.com> wrote:

> As the discussion thread has been quiet for a while, moving this RFC to
> voting.
>
> https://wiki.php.net/rfc/rng_fixes
>
> https://github.com/php/php-src/pull/1986


Votes are now closed. Results as follows:

* 19-5 - Fix mt_rand() implementation
* 21-4 - Alias rand() to mt_rand()
* 25-0 - Fix RAND_RANGE()
* 23-0 - Replace insecure uses of php_rand() with php_random_bytes()
* 24-0 - Make array_rand() more efficient

There are still a couple of tweaks to the implementation to be done before
merging:

* Make ranged output the same on 32 and 64 bit platforms where max-min is
less than 32 bits
* In compatibility mode use the old RAND_RANGE for mt_rand()

I intend to make time for these fixes tomorrow.

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

[Leigh]

On Sat, 9 Jul 2016 at 10:16 Christoph Becker  wrote:

>
> Assuming that "Make array_rand() more efficient" is indeed only about
> performance (and not about fixes for the broken implementation), it
> wouldn't be a bug fix, but as array_rand()'s behavior would change
> anyway as noted by the RFC, it makes sense to do it as well.
>
> Possibly badly worded by me. It makes the output of array_rand less
biased.

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

[Leigh]

On Sat, 9 Jul 2016 at 09:49 Pierre Joye  wrote:

>
> I am sorry but this PR possibly breaks BC and cases have been clearly
> explained how and why. Asking to show production  code publically is not
> something that you should request.
>
> I can write a sample app to show you how but given the explanations many
> gave already
>

Just to be clear, you voted no to one BC break, but yes to other BC breaks.
I don't know how you pick which ones are acceptable, and which are not.

Summary BC breaks you voted for:

* No to changing the output of mt_rand after calling mt_srand with a given
seed (when not specifying a min/max)
* Yes to changing the output of mt_rand after calling mt_srand with a given
seed (when specifying a min/max)
* Yes to changing the output of rand, shuffle, str_shuffle and array_rand

Do you see why this looks weird to me?

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

[Leigh]

On Sat, 9 Jul 2016 at 08:48 Pierre Joye  wrote:

> So, I voted no then as it is clear that you do not see a problem to
> break codes without a single warning or time to adapt before.
>
> The other sections are fine and voted yes.
>

For the part where you voted no. Still nobody has presented (publicly
available) source that makes legitimate use of mt_srand (yes it's mt_srand
that is "broken" here, not mt_rand) for deterministic streams of random
numbers. I can only assume by this that almost nobody does. However, for
those that do, they can still use the old algorithm.

For all of the other sections where you voted yes, they are mostly bug
fixes, but all change the output of mt_rand AND more functions (without a
single warning, like you wanted). I'm not trying to encourage you to change
any votes, but I need to make sure you understand what you're voting for.

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

[Leigh]

On 7 July 2016 at 21:33, Dan Ackroyd  wrote:
>> I think we need to drop the concerns about exposing "RNG state".
>>
>> If these are weak RNGs on your system, YOUR SYSTEM is broken.
>
> Telling people that their system is broken isn't going to be
> comforting to the people it happens to.

Of course it isn't. If I find out suddenly that /dev/urandom is
somehow predictable I would be incredibly uncomfortable. However the
least of my worries would be PHPs session id generation.

> There are always bugs in software and hardware. At some point it is
> almost inevitable that there will be some information leak through
> exposing the random numbers directly. Just telling people that their
> system is broken and they need to buy need hardware immediately,
> rather than just being able to re-enable hashing seems a bad choice.

I feel like we're back to the discussions around random_bytes() again.

The random number generators being used here are designated CS for a
reason. They are not like deterministic RNGs where you can give them
simple seed and produce the same set of outputs. They draw on
environmental noise for additional entropy and where appropriate they
reseed regularly, far before any useful statistical information can be
gathered.

In the case of urandom it actually performs a SHA1 on its pool,
CryptGenRandom mixes in data that has been MD4 hashed, arc4random_buf
is literally a stream cipher. These are well maintained and vetted
systems. An extra round of hashing is simply unnecessary overhead.

> But even without accidental bugs, the scenario I am remain concerned
> with is when a piece of hardware or software is compromised by a
> sophisticated attacker, (hello NSA!) and the 'random' numbers
> generated have some subtle pattern to them. To almost everyone, the
> random numbers generated would still look random. But to the
> organisation that compromised the system, and so knows the algorithm
> that is leaving traces in the random sequences, exposing the random
> numbers directly to the outside world would be an obvious but almost
> untraceable line of attack on the system.

I know it's easy to say: If your system has been compromised you have
bigger problems. But this is pretty much the fact of it. If someone
has the ability to make your system CSPRNG predictable, they can
almost certainly get anything else they want from the system anyway
without resorting to that.

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

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

[Leigh]

On 7 July 2016 at 13:39, Pierre Joye  wrote:
> Hi
>
> Looks good but missing an option to choose the default mode.
>
> I would choose BC as default at least for one release  (7.1).

It's been that way since 5.2.1, I think it's had enough releases already :)

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

[PHP-DEV] [RFC][VOTE] RNG fixes

[Leigh]

As the discussion thread has been quiet for a while, moving this RFC to voting.

https://wiki.php.net/rfc/rng_fixes

https://github.com/php/php-src/pull/1986

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

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

[Leigh]

On 6 July 2016 at 22:30, Yasuo Ohgaki  wrote:
> php_session_create_id() may return NULL. It's an usual error. Session
> module supports session ID creation save handler which may return
> anything valid for the type.
>
> Session module tries to call php_session_create_id() several
> places/times. If it could not get valid one, it raises
> E_RECOVERABLE_ERROR or E_ERROR eventually.
>
> Although it's not enabled yet, PHP_FUNCTION(session_create_id) returns
> FALSE it fails.

If it fails due to a lack of random, it throws a fatal. Tested your PR
and forced the fd of /dev/urandom to -1 in ext/standard/random.c

$ sapi/cli/php -n -r 'session_start();'

Next Exception: Cannot open source device in Command line code:1
Stack trace:
#0 Command line code(1): session_start()
#1 {main}
  thrown in Command line code on line 1

Fatal error: session_start(): Failed to create session ID: files
(path: ) in Command line code on line 1

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

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

[Leigh]

On Wed, 6 Jul 2016 at 13:10 Christoph Becker  wrote:

>
> Yes, I am aware that the patch uses php_random_bytes(), but what happens
> when it fails, in which case php_session_create_id() returns null[1]?
> Would it be impossible to use a session in this case?
>
> [1]
> <
> https://github.com/php/php-src/pull/1850/files#diff-52eb9eb7f9d5d9125fbb1337a6541c06R315
> >
>
> --
> Christoph M. Becker
>

The FAILURE check here is redundant because it is using the _throw variant
of random_bytes, which means an exception is thrown if there isn't a good
source of random available.

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

[Leigh]

On 5 July 2016 at 04:02, Pierre Joye  wrote:
> We can argue about the provided pnrng being CS but it is not php's job to
> decide.

I think we need to drop the concerns about exposing "RNG state".

A reminder of what php_random_bytes looks at (in order):
* CryptGenRandom on Windows
* arc4random_buf on modern BSD (where ChaCha20 is used)
* Linux getrandom(2) syscall where available
* /dev/urandom where available
* Throws an exception if it cannot access one of the above

If these are weak RNGs on your system, YOUR SYSTEM is broken. They are
all designed to be cryptographic quality.

If people are unconvinced we can temper the values with a secondary
RNG, but there is absolutely no need to generate session IDs using a
slow hashing algorithm.

For the record, I am +1 on removing hashing, -1 on the _other_ changes
in this RFC

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

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

[Leigh]

Actually decided to post so

On Sat, 2 Jul 2016 at 09:16 Leigh <lei...@gmail.com> wrote:

> On Sat, 2 Jul 2016 at 08:36 Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
>
>> Hi all,
>>
>> Currently session module uses obsolete MD5 for session ID. With
>> CSPRNG, hashing is redundant and needless. It adds hash module
>> dependency and inefficient (There is no reason to use hash for CSPRNG
>> generated bytes).
>>
>> This proposal cleans up session code by removing hash.
>>
>> https://wiki.php.net/rfc/session-id-without-hashing
>>
>> I set vote requires 2/3 support.
>> Please describe the reason why when you against this RFC. Reasons are
>> important for improvements!
>>
>
>
 So I have a few issues that span the RFC and the implementation.

Your RFC states

> hardcoded default and php.ini-* default values are the same.

This is not the case.

Originally the session id length and character set were controlled by
session.hash_function and/or session.hash_bits_per_character. These
customisations to configuration will be lost when the user upgrades. You
have provided a mechanism to control length and charset, but it will
require new changes to the default settings. This needs to be noted as a
breaking change.

Your default for session.sid_length is 48. Up to 7.1 the session id length
is 32. Your default for session.sid_bits_per_character is 5, up to 7.1 the
session id uses 4 bits per character. This is a breaking change. (Imagine
custom session handlers that validate session id character sets, or
database schemas that will truncate after 32 characters)

Your patch updates session.use_strict_mode from 0 to 1. I actually don't
know what this changes, but it's an undocumented change.

Overall your patch looks very similar to the one I was working on earlier
in the year, although you appear to have deleted a bunch of tests that you
could have just updated. You should probably put those back, and update
them.

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

[Leigh]

On Sat, 2 Jul 2016 at 08:36 Yasuo Ohgaki  wrote:

> Hi all,
>
> Currently session module uses obsolete MD5 for session ID. With
> CSPRNG, hashing is redundant and needless. It adds hash module
> dependency and inefficient (There is no reason to use hash for CSPRNG
> generated bytes).
>
> This proposal cleans up session code by removing hash.
>
> https://wiki.php.net/rfc/session-id-without-hashing
>
> I set vote requires 2/3 support.
> Please describe the reason why when you against this RFC. Reasons are
> important for improvements!
>

I support the idea proposed here, but I have issues with the
implementation. You've changed a lot of defaults that may break things for
some users (especially those using custom session handlers).

I'll add some notes on github.

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

[Leigh]

Updated RFC

* Removed proposal to replace (mt_)rand with an alternative algorithm
as many have expressed concerns with this.
* Clarified that the output of mt_rand _appears_ to be high quality as-is
* Added that the old mt_rand functionality will be available at
runtime via `mt_rand_mode()`

I'll have an implementation ready for review by the end of the week.

On 16 June 2016 at 19:54, Leigh <lei...@gmail.com> wrote:
> RFC updated to include:
> * A note about mt_rand()s poor performance
> * Separate votes for proposals so we can at least get the security fixes
> through
> * Updated vote from 50% to 2/3 as it does cause a BC issue.
>
> I should also state that mt_rand is easily implementable in userland, so the
> correct/legacy algorithm can be provided that way if changing it in core
> does not pass (I have a library providing this)
>
> So there have been a couple of suggestions of providing legacy functionality
> via a PECL extension. If we were to make rand/mt_rand use function pointers
> to their implementation it would be very easy for an extension to override
> their behaviour. If people like this idea I'm more than happy to provide
> this ext as part of the RFC.

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

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

[Leigh]

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

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

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

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

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

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

[Leigh]

RFC updated to include:
* A note about mt_rand()s poor performance
* Separate votes for proposals so we can at least get the security fixes
through
* Updated vote from 50% to 2/3 as it does cause a BC issue.

I should also state that mt_rand is easily implementable in userland, so
the correct/legacy algorithm can be provided that way if changing it in
core does not pass (I have a library providing this)

So there have been a couple of suggestions of providing legacy
functionality via a PECL extension. If we were to make rand/mt_rand use
function pointers to their implementation it would be very easy for an
extension to override their behaviour. If people like this idea I'm more
than happy to provide this ext as part of the RFC.

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

[Leigh]

On Wed, 15 Jun 2016 at 14:05 Jordi Boggiano  wrote:

> Just a thought here, if the goal is to provide a better interface,
> wouldn't it be better to use OO for this? Not because OO is better, but
> because it would avoid having problems if two mt_rand-using pieces of
> code are executed concurrently.


The goal is to fix inconsistencies. We absolutely can provide a better
interface as something separate though.

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

[Leigh]

On Wed, 15 Jun 2016 at 00:08 Tom Worster <f...@thefsb.org> wrote:

> On 6/14/16 12:46 PM, Leigh wrote:
>
> > The RFC can be found here: https://wiki.php.net/rfc/rng_fixes
>
> Hi Leigh,
>
> Thanks for putting this together. I am strongly pro on two points and
> moderately contra on the other two. I'd prefer separated votes, even
> though I don't have a vote. I numbered the 4 bullets in your intro 1 thru
> 4.
>

Noted, even though I'd like to "fix everything" at once, if separating the
votes is the only way to get the most important fixes in, then that's what
we'll have to resort to.


> 4. Insecure usage. I think we should replace the internal insecure uses
> of php_rand(). I can't see a reason not to.
>
> 3. Poor scaling of bounded outputs. I think RAND_RANGE() should be
> fixed. Users surely expect unbiased distribution. There's a BC argument
> but the bug is pretty serious. I think this should apply to array_rand()
> too.
>

Every point on the list causes a BC issue, it's up to us to judge which
ones are worth it. Some independent and some cascade into each other. I
just don't want to be in a situation where we cause some now, and some in a
future version.

1. Incorrect implementations.
>
> I don't think we should dictate that programs currently using mt_rand()
> shall use in future use MT19937 any more than we should dictate that
> XorShift64 or any other PRNG better fits their requirements.
>

I get your point, but most people probably use mt_rand() because "it's
better than rand". mt_rand is also incredibly slow and has a huge state
when compared to modern algorithms. I should probably note the performance
gains in the RFC.


> The incorrectness of the mt_rand() implementation with respect to its
> documentation can be fixed either in the code or in the docs. Given
> that, as far as we know, mt_rand()'s byte-stream looks like a decent
> PRNG[1] it's not clear that the actual MT19937 sequence is more
> important that backward compatibility. I for one think it's very unlikely.
>

I actually agree, (it was me who originally reverted the mt_rand fix in a
point release, citing BC as my reason to do so). I felt obligated to put
the decision up for a vote though, because I might have been wrong :)

I also don't think we should assume the responsibility of correcting
> people's insecure programs using rand() or mt_rand() (e.g. for keys,
> IVs, salts) by changing the algorithm. Programs this bad need more
> rework than we can provide. These functions have had scary-colored
> cautions on them for a long time.
>

We can only educate so far, I think we do have an obligation to provide the
best (no matter how subjective) possible algorithms to the end users.

Summarizing 2. and 3. it's not clear what we fix in the real world with
> the proposed changes to rand() and mt_rand(). But I do see BC breakage.
> I would prefer to fix these bugs the docs.
>

Changing mt_rand I don't see any real gain, but rand on the other hand has
platform-dependant output.

With respect to PRNGs completely new to PHP (you mentioned Xoroshiro128+
> and PCG), I would prefer completely divorce this question from the bugs
> discussed above. If some PHP users need efficient implementations of
> such algorithms then I would urge whoever wants to write them to use a
> new API and to provide them via PECL. In software, "better" is always
> with respect to context. While there are specific, well-known uses for
> random numbers (e.g. crypto) where we can make recommendations, in
> general we cannot.
>

I've been thinking of doing this anyway.

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

[Leigh]

On Tue, 14 Jun 2016 at 20:56 Davey Shafik  wrote:

>
> I think as this is a BC break it should require the 2/3 majority. I do
> support fixing the RNGs though.
>

Sure if there's a consensus on that, I have no problem with it.

Have you done any checks on GitHub etc to see how widespread this usage is?
> I'd like to get some data on that too.
>

I have checked, but it's really difficult to find legitimate use cases of
srand and mt_srand. I spent some time stacking up "NOT xyz" terms in the
search, and still didn't find anything that actually relied on
deterministic streams of numbers.

Re: [PHP-DEV] How to indicate support for unimplemented part of an RFC

[Leigh]

On Mon, 13 Jun 2016 at 22:30 Matthew Browne  wrote:

> Hi,
> What is the proper way to express support for an item that's not an
> official part of an RFC but is listed as an idea for future
> consideration? Specifically I wanted to give my "+1" for covariant
> return types which are mentioned in passing in this RFC:
> https://wiki.php.net/rfc/return_types.


I think you'd go ahead and create an RFC for it :)

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

[Leigh]

On Tue, 14 Jun 2016 at 19:14 Christoph Becker  wrote:

>
> In my opinion, we need at least one random function which yields
> reproducible values.
>
> --
> Christoph M. Becker
>

Hi Christoph,

Even with the proposed changes both functions will still be capable of
reproducible sequences, just different sequences than before the changes.

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

[Leigh]

On Tue, 14 Jun 2016 at 18:45 Fleshgrinder  wrote:

> Why do we need so many functions to get a random int anyways if we now
> have random_int()? I would like to see all of them deprecated and
> removed in PHP 8.0.


Lets see if others support this option. (I'm not even sure I do right now)


> I do not see a problem to change array_rand(), array_shuffle(), nor
> str_shuffle() since their output should be random anyways.
>

Right now a call to srand() with a given seed will make these functions
return the same sequence of outputs for a particular set of inputs. This
behaviour is fine and sometimes even desirable. The changes in this RFC
will change those outputs, they will still be controllable with srand()
though

[PHP-DEV] [RFC] RNG fixes

[Leigh]

Hey Internals,

I realise I'm cutting it close with this one, but I want to propose some
changes to our standard random number generators.

The downside of this proposal is that our RNGs (rand() and mt_rand()) are
seedable and reproduce identical streams (platform dependant) for any given
seed. However their implementations are broken or inconsistent, so we need
to weigh up the cost of changing these sequences versus having solid
implementations.

It is my opinion that if we are going to make any changes to these
functions, we should make all of the changes at the same time and avoid any
future disruption to their output.

The RFC contains a few proposals, some of them depend on each other while
others are standalone. Throughout the discussion phase I hope to reduce the
number of proposals down to a consensus we can vote on in two weeks time.

I will release a patch when I have a better feeling for the direction we
want to take.

The issues I want to bring up for discussion are.

* Replacing mt_rand() and rand() to a strong, modern RNG.
* Alternatively, fixing the current mt_rand() implementation to make it
standard
* Aliasing rand() to mt_rand() to improve output and cross-platform support
* Fixing RAND_RANGE for large ranges.
* Replacing insecure uses of php_rand() with php_random_bytes()
* Making the array_rand() algorithm more efficient

The RFC can be found here: https://wiki.php.net/rfc/rng_fixes

If anyone knows of other fixes that should be made at the same time but I
have overlooked, please let me know so I can get them included.

Regards,

Leigh.

Re: [PHP-DEV] Re: ext/curl update

[Leigh]

On Sun, 24 Apr 2016 at 01:25 Davey Shafik  wrote:

> Hi Pierrick,
>
> This should be in master for 7.1, alongside my RFC'ed patch for server push
> support.


I don't see why the additional constants that don't have a direct
dependency on your server push patch can't be committed to 7.0 as well. The
patch is pretty non-invasive.

The patch should hit in 7.1 but it has been requested that tests be added —
> and we can't add tests with a server push supporting HTTP/2 server against
> which to push.
>

The only new logic seems to be around CURLMOPT_PIPELINING_*_BL
and CURLOPT_STREAM_DEPENDS(_E). I don't know what these do, are they
related to server push? Is it possible to add deterministic tests for them?

Maybe in 7.1 we could bump the minimum version of cURL required too. #ifdef
version checks going back over 12 years seems unnecessary :)

Re: [PHP-DEV] Fw: unpack()

[Leigh]

On 25 February 2016 at 13:02, Dmitry Stogov  wrote:
>
> I've just got to know about possible usage of "@" in unpack(), but it seems
> doesn't work at all
>
> $ sapi/cli/php -r 'var_dump(unpack("@0l", "\x01\x00\x00\x00")); '
> array(0) {
> }
>
> Do I use it properly?
>
> Thanks. Dmitry.
>

As Nikita said, you need the "/". I use this operator when processing
streams of binary data.

Trimmed down example:

while ($blocks--) {
list(, $x0, $x1, $x2, $x3) = unpack("@$offset/N4", $message);
//...
$offset += 16;
}

The dynamic format string is kind of nasty though, so no objections to
an additional parameter making things clearer, however, what is to be
done if an offset is specified in both the format string and the
additional parameter? Does one override the other? Are they additive?

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

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Revert "Fix #71152: mt_rand() returns thedifferent values from original mt19937ar.c": ext/standard/rand.c ext/standard/tests/math/mt_rand_value.phpt

[Leigh]

I performed a similar test yesterday:
https://www.reddit.com/r/lolphp/comments/46fxi8/typofixing_commit_in_mersenne_twister_rng_code_is/d05zwgg

There is some discussion happening on the PR:
https://github.com/php/php-src/pull/1681

On Sat, 20 Feb 2016 at 04:04 Yasuo Ohgaki  wrote:

> Hi all,
>
> On Sat, Feb 20, 2016 at 10:39 AM, Andrea Faulds  wrote:
> >
> > Yasuo Ohgaki wrote:
> >>
> >> This should be discussed in internals.
> >> MT rand being not MT rand is unacceptable.
> >> This fix must included in released versions. IMHO.
> >>
> >> In any case we should provide broken MT rand, we must use INI switch
> >> or other options.
> >
> >
> > PHP's implementation of the Mersenne Twister algorithm is buggy, so it
> > doesn't produce the same output as in other languages. But the buggy
> > algorithm produces sufficiently random sequences of apparently the same
> > quality as the proper algorithm. So we *could* simply consider this as a
> > documentation issue if we wanted to. I'm not saying that's the right
> course
> > of action, though.
>
> It seems good enough for quick analysis via ent.
> Note: Ent tests per "byte", not php_uint32.
> http://www.fourmilab.ch/random/
>
> WITH FIX
> [yohgaki@dev rand]$ ~/git/oss/php.net/php-src/php-bin -r '$i =
> 100;while($i--) echo pack("I", mt_rand());' | ./ent
> Entropy = 7.954269 bits per byte.
>
> Optimum compression would reduce the size
> of this 400 byte file by 0 percent.
>
> Chi square distribution for 400 samples is 250901.85, and randomly
> would exceed this value less than 0.01 percent of the times.
>
> Arithmetic mean value of data bytes is 111.4725 (127.5 = random).
> Monte Carlo value for Pi is 3.486975487 (error 10.99 percent).
> Serial correlation coefficient is -0.049294 (totally uncorrelated = 0.0).
>
>
> WITHOUT FIX
> [yohgaki@dev rand]$ php -r '$i = 100;while($i--) echo pack("I",
> mt_rand());' | ./ent
> Entropy = 7.954382 bits per byte.
>
> Optimum compression would reduce the size
> of this 400 byte file by 0 percent.
>
> Chi square distribution for 400 samples is 250280.94, and randomly
> would exceed this value less than 0.01 percent of the times.
>
> Arithmetic mean value of data bytes is 111.5000 (127.5 = random).
> Monte Carlo value for Pi is 3.483663484 (error 10.89 percent).
> Serial correlation coefficient is -0.049192 (totally uncorrelated = 0.0).
>
>
> I'm not sure if this result is good enough to say "It's ok".
> MT rand has very long cycle and this quick test does not prove it.
>
> Did anyone do better analysis?
> Otherwise, I'm uncomfortable with basic algorithm change.
>
> 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] Allow specifying keys in list()

[Leigh]

On 19 January 2016 at 02:20, Andrea Faulds  wrote:
> After considering how to implement this at the opcode level, I've decided
> again that it's not worth it. Mixing keyed and unkeyed elements is not only
> an implementation nuisance (it's not necessarily hard, but it makes things
> more complicated), it's not something likely to be used in practice, and I
> think it's probably an indicator of bad code.
>
> Now, I can understand your case, but I don't really want to add a special
> exception for it. If we're allowing keyed or unkeyed, not both, then we
> should stick to it.
>
> Also, I realised that in your case (`list(7 => $a, $b, $c, $d)`), there are
> other, possibly cleaner ways to do it, such as:
>
> list($a, $b, $c, $d) = array_slice($array, 7);
>
> This way is simple and clear. It's probably clearer than `list(7 => $a, $b,
> $c, $d)` in fact. There's also this:
>
> list(($i = 7) => $a, ++$i => $b, ++$i => $c, ++$i => $d) = $array;
>
> This way is horrible, but at least demonstrates there are other ways to
> achieve what you want.

Thanks, I wouldn't worry about it. The use-case was hypothetical
anyway. I could see how I might use it, but I have nowhere at present
I'd actually use it.

list($offset => $a, $b, $b, $c) = $array;
$offset += 4;

vs.

list($a, $b, $c, $d) = array_slice($array, $offset);
$offset += 4;

Probably not worth the complexity overhead as you suggest, for what
amounts to (arguably) syntactic sugar. I also doubt it would see
enough usage to warrant the small gain of avoiding the fcall there.

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

Re: [PHP-DEV] [RFC] Allow specifying keys in list()

[Leigh]

On 18 January 2016 at 12:35, Lester Caine  wrote:

> > Hi!
> >
> > I found the idea convincing from the first read, but maybe it's just my
> > mind's assumptions about list() that I dislike the resulting syntax,
> > yet, it seems to be the logical choice.
> >
> > So, maybe I'm just trying to say, that I don't like list() to be reused
> > for that, but I don't have any better idea otherwise.
>
> As someone still using 'extract' in legacy code, I can sort of see the
> logistics of this, but why not just extend 'extract' to use the current
> object rather than the symbol table. It already has handling for
> duplicate keys and to prefix the 'array' name to the resulting variables.


The uses for this extended syntax go beyond simply populating object
properties, and shoehorning it into extract would pretty much limit it to
this use-case.

In favour of this improvement, although I would very much like to see
variable keys too (second option makes the most sense to me, as it's in
line with the syntax).

How feasible would it be to add an exception to mixed keys? I'm thinking
list(7 => $a, $b, $c, $d) to specify an initial offset, similar to how you
can define an array as [7 => 0, 1, 2, 3]. This obviously goes hand in hand
with my desire for variable keys :)

Thanks Andrea, looking forward to this.

Re: [PHP-DEV] Re: [RFC][VOTE] Number Format Separator

[Leigh]

On 18 January 2016 at 12:22, Lester Caine  wrote:
>
> My main need would be hexadecimal code
> which is not covered, so I still need the alternate hacks anyway.
>

Hex is covered, see the first examples in the "Proposal" section

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Leigh]

On Mon, 4 Jan 2016 at 21:07 Anthony Ferrara  wrote:

> Hey all,
>
> I have created a new RFC for the PHP Project to adopt the Contributor
> Covenant as the official Code of Conduct for the project
>
> https://wiki.php.net/rfc/adopt-code-of-conduct
>
> Let me know what you think or if there are any concerns
>
> Thanks
>
> Anthony
>

Perhaps cite the code of conduct as it would appear in the RFC body. We may
decide to make changes to the text to better suit our project, or the
linked site may go offline and it's nice to maintain a record of the
proposed text.

Sort of mixed feelings on this. I think mainly because we shouldn't need
such a policy, let alone a "response team" to enforce it. The intent is
unequivocally positive, and Eli's point makes sense. Absolutely not against
it, maybe just a little sad we feel it's necessary. Maybe someone else's
thoughts can capture my feelings better. I'll keep an eye.

Re: [PHP-DEV] HashDos protection

[Leigh]

On Thu, 26 Nov 2015 at 17:25 Nikita Popov  wrote:

> This will throw a fatal error if the number of
> collisions during an insertion operation exceed a certain threshold.
>

To me this feels like it's just moving a DoS vector from one place to
another.

As Niklas already pointed out, he is directly affected by this.

I was considering the scenario:
1) Open resources
2) json_decode
3) Do stuff
4) Clean up resources

This makes the DoS more application specific, but there's any number of
creative uses for making an application unexpectedly fail half way through.

You can argue it's similar to any DoS that causes a request to run out of
memory half way through, it is in some ways.

I don't think an exception is right for this either. People blindly catch
all exceptions because they can.

Not sure what to suggest.

Re: [PHP-DEV] 7.0.0 release

[Leigh]

On 23 November 2015 at 21:10, Anatol Belski  wrote:

> a) release on 26th including all known bug fixes
> b) do RC8, assume there are no bugs, so target 10th for RTM
> c) do RC8, release on 3rd, expect there are no bugs come in
> d) continue issuing release candidates till it's stable enough (needs
> definition of stable and probably an RFC)
>
> I would really ask to reach a consent on either a) or c). IMO, the options
> b) and d) are the direct road to curbing 7.0.0.  There is no hurry to
> release just to release, but it is definitely harmful to slow down the rise.
>
> Thanks
>
> Anatol
>

I prefer a over c.

As you said, we can deliver a stable and high quality 7.0.0 today. An RC
period where you expect no bugs does not sound productive to me.

We all know the "real testing" doesn't begin until it's released, and the
best way to find what is left (things we have not found in over a year of
development and testing), is to get more people looking at it.

Delaying the release is actually delaying the discovery of bugs that affect
real world applications that we do not have access to, and cannot test
with. Many teams will not even start testing with 7 until it gets an
official release.

If something is found, it doesn't make the release any less high quality.
Any bugs that would be found between now and the 3rd will still be found
(and probably more), and they will still be fixed. The only difference
would be a 0.0.1 version number.

/2c

Re: [PHP-DEV] Null bytes in anonymous class names

[Leigh]

On 9 November 2015 at 16:42, Niklas Keller  wrote:

>
> Having the path info is quite useful for debugging purposes.
>
> Regards, Niklas
>

It is, but it will always still be available from
ReflectionClass::getFileName()

Re: [PHP-DEV] Null bytes in anonymous class names

[Leigh]

On 9 November 2015 at 15:27, Steven Hilder
>
>
> So, I prepared a patch for `get_class()` and `ReflectionClass::getName()`,
> which in my view should behave the same way as `var_dump()` etc., but I've
> now realised that ignoring the unique suffix from the class name will break
> functionality that is otherwise desirable:
>

Can you share your patch?

It should be possible to return the sanitised name without removing it
internally.(would have to cover the get_parent_class and getParentClass
versions too, and have a quick audit of other places class names can be
spat out.)

Can we at least get the memory address hidden (non-debug builds only
perhaps? - var_dump appends a #n why not just use this number.)

Re: [PHP-DEV] Null bytes in anonymous class names

[Leigh]

On 5 November 2015 at 14:21, Niklas Keller  wrote:

> Hello,
>
> I discovered today that anonymous class names contain a null byte right
> after "class@anonymous". I don't think class names should contain
> non-printable characters.
>
> How about removing that null byte?
>
> https://3v4l.org/QUKpV
>
>
> https://github.com/php/php-src/blob/da8e6ec4a5063d9f60f83f43c55bc17d015cac8b/Zend/zend_compile.c#L5207
>
> Regards, Niklas
>

It's also quite worrying that it is leaking memory addresses.

Re: [PHP-DEV] Null bytes in anonymous class names

[Leigh]

On 5 November 2015 at 14:59, Rowan Collins  wrote:

>
> PHP uses null bytes quite a lot to produce deliberately illegal
> identifiers. For instance the old eval-like create_function() [e.g.
> https://3v4l.org/hqHjh] and the serialization of private members [e.g.
> https://3v4l.org/R6Y6k]
>
> In this case, I guess the "@" in "class@anonymous" makes the name illegal
> anyway, but I'm not sold on the null byte being more unacceptable here than
> anywhere else.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> That doesn't mean it's a good approach (*cough* namespaces *cough*), and
these bits of "magic" are supposed to be hidden away from users. I'm
guessing in this particular instance, the point of the null is to make
string operations cut off after "anonymous", however string operations that
respect the zval string length aren't going to do this.

e.g. var_dump() the class name is put through sprintf and it cuts off at
the null, but get_class or ReflectionClass::getName() just returns the
original string, and exposes the implementation details.

Re: [PHP-DEV] Re: Friend class/function

[Leigh]

On 2 November 2015 at 09:25, Rowan Collins  wrote:

> Andrea Faulds wrote on 01/11/2015 19:35:
>
>> I recently wished PHP had this feature when trying to implement the
>> Khronos Group Typed Arrays specification in PHP, which requires sharing
>> certain data between unrelated (inheritance-wise) classes. I ended up
>> having to expose a public method to get the data, but named in a way that
>> was likely to deter use.
>>
>
> Would "package" (namespace-based) visibility have solved the problem in
> this case? That's something I've often wanted - "this is public within this
> Lib, but should never be used outside it".
>
> This was worked on for 7, but had a fundamental problem blocking it - See
Guilherme's recent runtime execution scope mail.

[PHP-DEV] Re: Make sessions use php_random_bytes in 7.1

[Leigh]

On 1 November 2015 at 16:07, Tom Worster  wrote:

>
> I don't have one.
>
> But if I may ask, I'm curious, as always: What happens in the case that
> php_random_bytes() fails?
>
> Tom
>

That's a good point.

session_start() would throw the exception generated by php_random_bytes()
letting you know your system is incapable of generating high quality random
numbers. However this is a serious issue in it's own right, the APIs used
(and the way they are used) really only fail if the underlying environment
is fubar.

[PHP-DEV] Make sessions use php_random_bytes in 7.1

[Leigh]

Hi all,

I would like to refactor session id generation to use our new
php_random_bytes API as the single entropy source for session ids,
targeting 7.1

Overall this would give a small performance increase to session generation,
a large security increase to session generation, and remove some points of
possible user error.

There are a few things to consider while doing this:

session.entropy_file will no longer needed, as the best source of random
for the operating system will be selected.

session.entropy_length should be ignored, as this was to specify the length
of *additional* entropy, and may be non-zero in legacy configuration files,
that are preserved across upgrades

session.hash_function should be deprecated, there is no benefit to hashing
cryptographically strong random bytes, however people may be relying on
this to get session ids of a certain length.

We will have to introduce a new setting to control session id length,
perhaps overridden if session.hash_function is non-default. We have a year
to play with the details.

I'd like to hear if there are any strong objections to this proposal.

Cheers,

Leigh.

Re: [PHP-DEV] Support execution scope realization at runtime (or last pieces for private class support)

[Leigh]

On 29 October 2015 at 02:57, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> I wonder what would be necessary to make this patch possible, if there's
> any interest to move this forward and potentially target it for 7.1
> release.
>
> I'm still interested in this, and willing to help out with implementation
if required.

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Remove arc4random: ext/standard/config.m4 ext/standard/random.c

[Leigh]

On 28 October 2015 at 09:51, Anatol Belski  wrote:

> Yeah, I was only talking about those two OS versions that are known for
> sure to have proper implementations. Even that is a smaller community than
> fe Linux, IMHO no reason to handicap users, especially as the corresponding
> codes are present and would need just a condition to extend. It's not that
> anyone would judge what is secure, but based on the fact that ChaCha is
> already used, is being widely adopted and there's no evidence of any flaws.
> Probably when it is implemented in more places like other more popular BSD
> and Solaris forks, we'll see some patches to PHP anyway.
>
> Are you saying you would like me to add arc4random back in, conditionally
for those OS versions only?

I'll test on VMs obviously, but it looks like it should only require:

#if defined(__OpenBSD__) || defined(__NetBSD__)
#  include 
#endif

#if HAVE_DECL_ARC4RANDOM_BUF && ((defined(__OpenBSD__) && OpenBSD >=
201405) || (defined(__NetBSD__) && __NetBSD_Version__ >= 70001))
  arc4random_buf(bytes, size);
#elif
 ...

201405 maps to the 5.5 release date.

[PHP-DEV] Re: [PHP-CVS] com php-src: Remove arc4random: ext/standard/config.m4 ext/standard/random.c

[Leigh]

Hi Anatol,

On 26 October 2015 at 21:58, Anatol Belski  wrote:

> Which discussions do you mean, could you please link to them? The one I
> remember right now is https://github.com/php/php-src/pull/1513 , but
> there's actually no obvious conclusion. Removing arc4random is quite a
> radical move, but OpenBSD and NetBSD could still profit from not using
> /dev/urandom and it would cost just extending the macro condition.
>
> Thanks
>
> Anatol
>
> There has been a lot of small discussions in the past 6 months in various
places, I cannot link to all of them. Most recently
https://bugs.php.net/bug.php?id=70744 which created an offline discussion
between myself, Tom W and Anthony F.

There have been pro and con discussions, but in the interest of security
the cons weigh more heavily.

The biggest con is that arc4random has been around for a long time, and
different platforms/versions have implementations that range anywhere
between very flawed and very strong. We cannot guarantee cryptographic
quality on all platforms.

We could conditionally include it on platforms where WE think it is secure
(this extends beyond the use of ChaCha20 - which there hasn't been much
public cryptanalysis on at all). At present it looks like the only OSes to
implement the whole security model correctly (i.e. zeroing state on fork,
killing process if entropy could not be obtained from the kernel, etc.) are
OpenBSD 5.5+ and NetBSD 7

Do we want the responsibility of judging which implementations are secure,
and maintaining that list?

It's a difficult place to be in, people on one side saying it's a good idea
to include it, people on the other side saying it's not. I've gone with
"I'm not sure, so better to be safe"

Re: [PHP-DEV] PHP 7.1 - should we add a random_str() function?

[Leigh]

On Wed, 30 Sep 2015 17:15 Scott Arciszewski  wrote:

This is probably answerable by a quick yes/no and shouldn't need a ton
of bikeshedding, but if that happens anyway I apologize in advance.

I think random_bytes() and random_int() are great; they provide a
much-needed building block in PHP 7.0. However, I do worry a bit that
the most common use for random_int() (generating a random string of a
fixed length with a given character set) will be reinvented over and
over again, and rarely consistently.

I would propose a random_str() function that behaves similar to this
userland snippet: http://stackoverflow.com/a/32870871/2224584

Function prototype:

> string random_str( int $length, string $charset)

Would return a string or throw an Error|Exception (e.g. invalid input
parameters, or the operating system's CSPRNG begins to melt).

I can write up an RFC for this, with a patch targeting 7.1, if anyone
is interested in it.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 

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


Hey Scott

Just quickly for reference, there was some discussion on this before in
Feb, roughly here: https://marc.info/?l=php-internals=142481367620609=2

Not sure how relevant, havent reread it.

Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7

[Leigh]

On Thu, 6 Aug 2015 00:55 Scott Arciszewski sc...@paragonie.com wrote:

All,

I'd like to move the conversation towards a decision regarding PRs
1397 and 1398. These decisions are blocking random_compat as well as a
security enhancement to random_bytes (merge conflicts are *the
worst*).

Here's a quick recap

Arguments:

1. Consistency is more important than security.

 random_* should be consistent with the rest of PHP (sans intdiv()).
 They should return false and emit an E_WARNING
 or E_ERROR warning (the latter is if we want it to fail closed).

 It's the responsibility of the developer to know this can
 happen and explicitly check for it. Don't throw anything.

2. Security is more important than consistency.

 Placing more responsibility on the developer increases the
 likelihood of an implementation error. We should aim for compatible
 usability with rand() and mt_rand() for random_int(), which never return
 false. For random_int() and random_bytes(), should PHP be unable
 to generate a random value (no random device available, file
 descriptor exhaustion, etc.) an exception should be thrown. If the
 developer wants to handle it gracefully, they can place it in try/catch
 blocks (which raising errors make messy). Otherwise, the default
 state is to fail closed (i.e. terminate script execution).

Open Questions:

1. Under what conditions should an Exception be thrown, and which
should throw an Error instead?

Did I miss any?

I'm in favor of throwing *something*. As for the particulars of what
should be an Exception and what should be an Error, I don't have a
horse in this race. Exceptions already existed and Errors were already
accepted in the Throwable RFC, so I don't believe this warrants
another RFC and putting this decision off until 7.1.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com

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


We also -need- a consensus in place because we have more security sensitive
features targeting 7.1 and we don't want to have this argument again.

Throwing exception's may not be consistent right now, but it certainly
should be in the future. The transition to a new consistency has to start
somewhere.

Re: [PHP-DEV] PHP 7.1 Cryptography Projects

[Leigh]

On Mon, 3 Aug 2015 at 21:54 Scott Arciszewski sc...@paragonie.com wrote:

 Hi,

 I would like to make it easier for PHP developers to implement
 cryptography features in their applications. I intend to work on some
 of these ideas and submit them for inclusion in PHP 7.1.

 Some of these might be familiar to some of you.

 1. Pluggable Cryptography Frontend

 Work is currently underway for a PHP prototype for this idea
 originally suggested by ircmaxell, that will basically be like PDO for
 cryptography. Our current project name, subject to change, is PHP
 Crypto Objects (PCO).

 The idea is that you could write code like this to add secure
 authenticated encryption to your application without having to worry
 about the details.

 $AES = new \PCO\Symmetric('openssl:cipher=AES-128');
 $ciphertext = $AES-encrypt($plaintext, $someKey);

 $PKC = new \PCO\Asymmetric('libsodium');
 $offlineDecryptable = $PKC-seal($plaintext, $someX25519PublicKey);

 When it's finished, I'd like to turn it into a PECL extension so users
 can play with it in PHP 7.0 and submit it for inclusion in 7.1.

 2. Cache-timing-safe character encoding functions

 Alternatives for existing functions that should function like their
 unsafe counterparts, but without branches or data-based index lookups.

 * hex2bin() - hex2bin_ts()
 * bin2hex() - bin2hex_ts()
 * base64_encode() - base64_encode_ts()
 * base64_decode() - base64_decode_ts()

 Other formats are out of scope, unless someone can make the case that
 we need to support RFC 4648 base32 encoding (e.g. for Tor Hidden
 Service integration).

 3. Other ideas (not yet committed to at all, but might be of interest
 to others):

 * Improving the OpenSSL API, or at least the documentation
 * Adding streaming encryption/decryption support to OpenSSL
 * Adding AE and AEAD interfaces to OpenSSL
 * Aliasing MCRYPT_AES - MCRYPT_RIJNDAEL_128, adding MCYPT_MODE_CTR

 What I need from you is guidance on what features or changes you want
 to see in 7.1 and which can be put off until later (or never proposed
 as an RFC at all).

 Seriously, all I need is your opinion and whether or not you'd like to
 see any of these happen. If you have specific implementation details
 you'd like to discuss or requests, of course those are welcome too. :D


I wrote about something similar earlier in the year, although the timing
was probably pretty bad with all of the scalar type arguments going on.

http://marc.info/?l=php-internalsm=142365688004941w=2

I'm obvious +1 on the concept.

There's a couple of other things I would like to see in addition to what
you have proposed.

* AES-*-CTR native without a back-end. There is a ton of trusted reference
code for this, and (probably) removes the reliance on an extension for the
majority of PHP crypto use-cases.

* As others have said, lets try and avoid the evil DSN - we're trying to
make it easy for users to get it right here. Ideally there should be enough
metadata so a user can request a cipher without a back-end, and appropriate
back-end will be selected if available.

* I'd like to see some hashes as part of this, not everything from
ext/hash, but being able to have a hash as a stream filter would be great

* An API that makes it easy for extensions to register metadata /
implementation for a cipher/hash/whatever they provide

Re: [PHP-DEV] 7.0 Release Management

[Leigh]

On 29 April 2015 at 14:21, Anatol Belski anatol@belski.net wrote:

 after the recent discussion on IRC I would like to express the rediness to
 take on this job. As Kalle is willing to take this role as well, it'd
 probably make sense to hear what everyone thinks about my proposition.
 Possibly it could come to an election then.

 I guess this thread conjuncts with the PHP7 RM one started last year by
 Kalle.

 Regards

 Anatol


Hey Anatol,

From my memory of your previous work, you do a lot for the Windows
platform? I think it's a huge bonus that one of the RMs has this focus. I
expect a large amount of casual testing leading up to GA will be done by
people who just want to download on their desktop and try things, and
quality Windows builds will help a lot.

Many thanks for nominating yourself.

Cheers,

Leigh.

Re: [PHP-DEV] [RFC] [VOTE] Vote open for reliable user-land CSPRNG

[Leigh]

Hi all,

Voting has now closed on this RFC. The feature has been accepted for PHP 7
with votes of 41 - 0.

Thanks to all who participated in the discussion and gave feedback.

Regards,

Leigh.

Re: [PHP-DEV] RFC: Nested enclosing returns

[Leigh]

On 21 March 2015 at 12:13, Georges.L cont...@geolim4.com wrote:

 Hi php internals,

 After some long and deep research i finally decided to write my first RFC
 about a feature i'd be interested to be improved in the php core: *Nested
 enclosing returns*


 The main purpose, as the title say, is to have the possibility to nest
 multiple return like we can do currently with break/continue.

 I thinks it'll being better with a scheme:




 function foo($foo = true)
 {
if(!$foo)
{
   return false, 3;// Please note the second return argument is the
 return nesting level
}
else
{
   return true;// Default nested return argument is always equal to
 1 (if not specified, current)
}
 }

 function bar($foo = true)
 {
foo($foo);
// Some stuff that will never be executed if $foo == false and
 nested return argument = 2
echo 'Hi jon !';
 }

 function baz($foo = true)
 {
echo 'Hi bertie !';
foo($foo);
// Some stuff that will never be executed if $foo == false and
 nested return argument = 3
echo 'Hi freddy !';
 }


 baz(true);  // Display:
  //  Hi bertie !
  //  Hi jon !
  //  Hi freddy !

 baz(false);  // Display:
  //  Hi bertie !


 Benefits:
 -Wont break compatibility
 -May improve code interpretation speed due to part of code skipped by the
 nested return.
 -Allow dynamic return expressions.

 Inconveniences:
 -May complicate debug/backtrace


I think this will lead to a debugging nightmare, sorry.

It allows functions to behave in an incredibly non-obvious way, makes it
really easy to break things, and when something is broken the complexity of
locating and fixing it feels like it will be insane.

I'm imagining functions with branches that have different return levels in
them, called from functions with branches with different return levels in
them I feel like crying and it's not even a real feature yet!

Re: [PHP-DEV] To RFC or Not To RFC [was Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function]

[Leigh]

On 22 March 2015 at 08:54, Patrick Schaaf p...@bof.de wrote:

 Okay, that's easier to implement and probably sufficient,  if everybody
 play nice. Or, another idea and maybe a lot less work to implement: all
 active release managers could have a want a vote button on pending RFC
 pages.

+1 on RM sign-off for immediate merge, or requesting a vote first.

Re: [PHP-DEV] To RFC or Not To RFC [was Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function]

[Leigh]

On 22 March 2015 at 07:00, Patrick Schaaf p...@bof.de wrote:

 Hmm. Is that really the line to be drawn? An RFC, by itself, provides a
 good point to spell out a change clearly, and anchor it for reference in
 discussion. Discussion on internals itself cannot provide that, it is too
 scattered, and POC code provides it at the code layer only. Thinking about
 documentation, for example.

Sure, I can agree on RFC all the things.

 So, maybe the line is better drawn at what needs a vote, and what does not?

 Just an idea: as soon as an RFC goes up / leaves draft state, could it
 have a needs a vote? prevoting section? And if a certain minimum opts for
 needs a vote (within a minimum discussion period after leaving draft),
 one must be held? (thinking about a one week period and three or five
 needs-a-vote calls, or something similar)

I suppose this could be part of the discussion on list when it is not
obvious, then we at least have some documented opinions on the decision,
rather than the assumptions of individuals.

Re: [PHP-DEV] 7.0 Release Management

[Leigh]

On 22 March 2015 at 07:49, Pierre Joye pierre@gmail.com wrote:

 From A RM point of view, I agree with other here, I could not think of
 a better person than you as one of the RMs. You did and still do a
 fantastic job, keeping things up and running, awesome communications,
 etc. As a 2nd RM, I would like someone with good low level knowledge
 and have a given objectivity. Anthony would be awesome, now that he is
 back :)


I agree, but I think people need to nominate themselves. I'm totally +1 for
Kalle. He's been kicking around for long enough, and as far as I have seen
has always been pretty pragmatic.


 I also agree that branching too early will create some extra work
 which may be counter productive for now.


Alright, I guess I'll feel more comfortable with this when we have our
chosen RMs who will say no to sneaky merges :)

Re: [PHP-DEV] 7.0 Release Management

[Leigh]

On 22 March 2015 at 13:33, Yannick Komotir ykomo...@gmail.com wrote:

 Hi,

 I am sorry if I am wrong but why it is not people that started php 7/ng
 project ? Dmitry, Nikita or Xichen ?

Personal opinion: I'd prefer all of these people had more time to work on
code, and didn't have to worry about RM duties :)

Re: [PHP-DEV] To RFC or Not To RFC [was Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function]

[Leigh]

On 21 March 2015 at 12:30, Peter Cowburn petercowb...@gmail.com wrote:

 On 21 March 2015 at 08:14, Xinchen Hui larue...@php.net wrote:

  Hey:
 
  On Fri, Mar 20, 2015 at 9:14 PM, Xinchen Hui larue...@php.net wrote:
   Hey:
  
   On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams a...@phcomp.co.uk
  wrote:
   On Fri, Mar 20, 2015 at 10:46:58PM +1100, Pierre Joye wrote:
   On Fri, Mar 20, 2015 at 7:03 PM, Wei Dai zxcvda...@gmail.com
 wrote:
Hi internals,
Hi internals,
   
The RFC to add a user-land function for an easy-to-use and
 reliable
preg_replace_callback_array() in PHP is up for discussion:
https://wiki.php.net/rfc/preg_replace_callback_array
   
This proposes adding one function: `preg_replace_callback_array()`
  that
is the better way to Implement when there are multiple patterns
  need to
replace.
   
I would love to hear your feedback! :)
Any objections?
   
I’ve sent this mail for four days, I don’t know if this RFC needs a
  vote.
If you guys have no objections on this, please review the code and
  merge it,
thanks.
  
   Nice job, i like the idea.
  
   I am not sure about a RFC or not. It somehow looks like a sane
   replacement for something we killed (with good reasons).
  
   Let see what the other think :)
  
   I used s/something/code/ge in a perl script that I wrote a few days
  ago. Very
   useful. It would have been a lot more work to do it another way.
  
   So: +1 to the ability to do this, regardless of what mechanism is
  eventually chosen.
  
   I also +1 for this.
  
   if there is no objections raises, I am going to merge it tomorrow..
  merged
 
  thanks
 



 Whoa, hold on there a second.

 An RFC was created, presumably intending to follow that line of procedure.
 Then Xinchen comes along and puts a middle finger up to the whole process,
 reverts back to the old if no-one complains by tomorrow, merge it
 approach, then does the merge.

 I'm all for avoiding the potentially unnecessary red tape of the RFC
 process. Particularly for small, standalone changes like this. I fear there
 are other who aren't so lenient.

 Thoughts?..


Yep, this does look like another case of simply ignoring rules. The fact
that what does and does not require an RFC does not help, this probably
didn't need one, however one was created and the rules need to be stuck to.

Instead of forcing this change to be reverted, because it really is
self-contained, we need a succinct wiki document on what does and doesn't
require an RFC.

[PHP-DEV] 7.0 Release Management

[Leigh]

Hi all,

With 7.0 feature freeze in effect, and proposals and RFCs still coming in
that are going to target 7.1, I think it's time we branched master and
selected a release manager (or two) for 7.0.

Traditionally the newer RM from the previous release stays on, and a new RM
is introduced who will remain for the next two releases. So in this case it
would be Ferenc + 1.

However this is a major release and we obviously have to make sure Ferenc
is happy to keep this position. So, Ferenc? How do you feel? :)

Do we have any candidates willing to put their name forward as possible
second RM?

Cheers,

Leigh.

Re: [PHP-DEV] RFC - Array slice syntactic sugar

[Leigh]

On 20 March 2015 at 10:38, Leigh lei...@gmail.com wrote:

 I've tried implementing python style slice on both strings and arrays in
 the past (I don't seem to have an existing branch with it in any more
 though it seems). The biggest problems I hit were regarding the syntax, the
 functionality itself worked.

 Colons caused problems with ternary operators in the lexer, and I had an
 issue with commas too, but I forget what it was. Of course these might have
 been resolvable, but I didn't put too much effort into it.


 That said, I'm a little older and wiser than I was then, I'd still be
interested in looking at this. I'll try and come up with _something_ that
works over the weekend.

Re: [PHP-DEV] RFC - Array slice syntactic sugar

[Leigh]

On Mar 20, 2015 12:33 PM, Alex Bowers bowersb...@gmail.com wrote:

 We also need to consider then the possibility of setting data by position.

 What should $array[@1:3]  = [1,2,3] do?

 Should it overwrite the values there, and append any that don't exist, or
 should it be a parse error?

I'd say overwrite/replace the range with the new value.

Re: [PHP-DEV] RFC - Array slice syntactic sugar

[Leigh]

On Mar 20, 2015 11:40 AM, Alex Bowers bowersb...@gmail.com wrote:

 I've tried implementing python style slice on both strings and arrays in

 the past (I don't seem to have an existing branch with it in any more
 though it seems). The biggest problems I hit were regarding the syntax,
the
 functionality itself worked.


 If you've got a link to your messaging thread, I'd love to read it. Thanks

 Colons caused problems with ternary operators in the lexer, and I had an
 issue with commas too, but I forget what it was. Of course these might
have
 been resolvable, but I didn't put too much effort into it.


 Could this not be mitigated by adding a new token like T_COLON to be used
to match this use case?

The only thing I could find is:
http://chat.stackoverflow.com/transcript/11?m=15926856#15926856

If your branch is available on github let me know, more than happy work on
it with you.

Re: [PHP-DEV] RFC - Array slice syntactic sugar

[Leigh]

On Mar 20, 2015 2:59 PM, Alex Bowers bowersb...@gmail.com wrote:

 
  So $dictionary['elephant':'snake'] returns all elements with keys which
  sort lexically between 'elephant' and 'snake', regardless of whether the
  array is sorted.


 Makes sense to me.

 Alternatively, a key-based slice could look up the position in the array
of
  the two keys, and then perform a positional slice between those
positions,
  i.e. $array[$a:$b] == $array[ @ key_position($array, $a) :
  key_position($array, $b) ]. I'm not sure that's particularly intuitive
or
  useful, but again, it has no problem with string keys.


 I'd say no to that, since it is not an obvious use case, since if you are
 defining associated arrays, going for the indexes of those fields feels
 strange; since one of the major benefits to associated keys is that the
 order doesn't matter anymore. Having this one feature order dependant
 whilst using the associated keys isn't correct in my view.

 On 20 March 2015 at 14:41, Rowan Collins rowan.coll...@gmail.com wrote:

  Alex Bowers wrote on 20/03/2015 13:40:
 
  Still not sure how we can implement a range of strings. But since thats
  for a different feature, I'll leave that issue for now.
 
 
  I can't resist a quick answer: if you can define a key-based slice at
all,
  you can define it for both integer and string keys. Bear in mind the a:b
  here isn't a range, it's just a pair of values specifying which items to
  include in the slice.
 
  If the definition of a key-based slice is all elements whose key
  satisfies $key = $a  $key = $b, then you're just doing comparisons
  between strings, which are defined as lexical order. So
  $dictionary['elephant':'snake'] returns all elements with keys which
sort
  lexically between 'elephant' and 'snake', regardless of whether the
array
  is sorted.
 
  Alternatively, a key-based slice could look up the position in the array
  of the two keys, and then perform a positional slice between those
  positions, i.e. $array[$a:$b] == $array[ @ key_position($array, $a) :
  key_position($array, $b) ]. I'm not sure that's particularly intuitive
or
  useful, but again, it has no problem with string keys.
 
  Regards,
  --
  Rowan Collins
  [IMSoP]
 

IMHO, stick to offsets in the first instance, this is a slice notation,
first order of business is to make it behave like array_slice (+on
strings). Assoc key based slicing feels pretty wrong to me at this point.

Re: [PHP-DEV] RFC - Array slice syntactic sugar

[Leigh]

On Mar 20, 2015 4:00 PM, Alex Bowers bowersb...@gmail.com wrote:

 IMHO, stick to offsets in the first instance, this is a slice notation,
first order of business is to make it behave like array_slice (+on
strings). Assoc key based slicing feels pretty wrong to me at this point.


 I have to agree, we are getting ahead of ourselves.

 A quick summary of what this RFC should cover:

 - Slicing an array or string based on the positional index.

 Things for future RFC consideration:

 - Slicing an array or string based on the key.
 - Index -1 for last item of list.

 Everybody agree that the only focus of this RFC should be the positional
index slicing?

I think that's plenty for initial scope, since at this point proposals are
targeting 7.1 there's plenty of time to get assoc indexing in if there is
enough support for this in the first instance.

If there is support for positional but not assoc, we don't want this
proposal to fail on the fact they are bundled together.

Not sure I understand your index -1 line (sorry, on phone in pub, really
just skimming mails). If you mean negative indices for positions from the
end of the array/string then +1 for this *with* the slice syntax.

For $thing[-1] I think this only works for strings (and I have this
implemented, should probably RFC it)
https://github.com/lt/php-src/tree/string_negative_offset

$thing[-1:] is in scope for arrays though

Re: [PHP-DEV] [VOTE] Reserve even more type hints

[Leigh]

On 16 March 2015 at 23:37, Dan Ackroyd dan...@basereality.com wrote:

 In particular the keywords 'Resource' and 'mixed' seem to have limited
 need to be reserved. I don't believe there has been any suggestion
 that either of these would actually be used as types for PHP 7.x. So
 making them be unusable seems to be a large BC hit for no gain for
 people who currently have classes that use them


I agree, mixed seems to serve no purpose (just don't hint the parameter,
same result). Resource is something we're hopefully going to phase out over
time as they get replaced with objects (like Nikita already did with GMP,
and hopefully will happen to streams some time between now and 7.1 :)).

It's possible that people are voting yes to reserve these two words,
 without fully considering whether they should be reserved or not. I
 can see that all of 'object', 'scalar', and 'numeric' have been
 proposed as part of future improvements to PHP's type system.


I don't really like scalar or numeric (but I'm in the strict types camp and
I think if union types ever make it in, they should be user definable).

Object makes sense to me though, apart from resource it's the only one that
represents a single underlying type.

Re: [PHP-DEV] [VOTE] Reserve even more type hints

[Leigh]

On 17 March 2015 at 07:08, Leigh lei...@gmail.com wrote:

 I agree, mixed seems to serve no purpose (just don't hint the parameter,
 same result). Resource is something we're hopefully going to phase out over
 time as they get replaced with objects (like Nikita already did with GMP,
 and hopefully will happen to streams some time between now and 7.1 :)).


It has been pointed out to me, that mixed is useful for being explicit,
rather than having a single untyped parameter amongst typed ones, you know
that it was designed to accept anything rather than being an oversight.

Completely valid point.

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

[Leigh]

On 17 March 2015 at 08:37, Lester Caine les...@lsces.co.uk wrote:

 To help towards that end, can someone who understands what is wanted
 from the weak type hint mode actually produce a summary of that as it is
 very difficult to extract just what has now been agreed for that area of
 type hinting. A base that can be used to review some of the other
 discussions to put that to bed. Others might appreciate a similar
 summary of the 'type_error' mode as well? As a base for the
 documentation on the user manual updates?


Not sure what is difficult to extract

https://wiki.php.net/rfc/scalar_type_hints_v5#behaviour_of_weak_type_checks

It's all right there...

Re: [PHP-DEV] [RFC][VOTE] Reserve More Type Names in PHP 7

[Leigh]

On 16 March 2015 at 04:58, Levi Morrison le...@php.net wrote:

 Dear Internals,

 I am tentatively opening the vote on this RFC:
 https://wiki.php.net/rfc/reserve_more_types_in_php_7

 It's a bit tentative because I would prefer to wait until the vote on
 Anthony's RFC closes tomorrow as there is some overlap in the type
 names reserved. However, I am unsure if I am allowed to wait one more
 day, as today is March 15th.

 In any case, voting is now open.

 Cheers,

 Levi Morrison


Thanks Levi, I'm glad the aliases were removed, this was the point of
contention for me.

Re: [PHP-DEV] [RFC][VOTE] In Operator

[Leigh]

On 16 March 2015 at 08:04, Lester Caine les...@lsces.co.uk wrote:

 Some of this Syntactic sugar would in the past have been developed in
 PEAR, but the support for 'userland' solutions via that path seems to
 have lost favour, with even the suggestion that PEAR should be dropped?
 Perhaps if PEAR contained examples of good practice in these areas it
 would help. I'd even perhaps go as far as suggesting that some of the
 more exotic developments in core would benefit from up to date demo's of
 their use in PEAR?


And how do you propose the lexer/parser is extended in this manner?

Re: [PHP-DEV] Re: A plea for unity on scalar types

[Leigh]

On 15 March 2015 at 08:42, Pavel Kouřil pajou...@gmail.com wrote:

 Sure, per-file is better than ini setting, but better doesn't mean
 good (because it is still a pretty bad approach). The ini setting at
 least has the option to be turned off in code once everyone realizes
 it was a bad idea (register_globals via htaccess, for instance), but
 PHP would be stuck with the declare for a long time - this is not an
 easily revertable change, once PHP ships with it.


The declaration is turned on with code. This is no different to changing an
ini setting with code, except that it can't be configured globally in
advance.

Existing code is unaffected. I'm not sure where your not easily
revertible argument is grounded. It's incredibly easy to add/remove
declarations at the top of a file.

The two groups (people who want strong typing and weak typing) will
 not work *together* though. And it will be a nightmare for everyone
 working on multiple projects from mulitple clients or so.


Pure FUD. Sorry but there is no evidence to back this up.

PHP will IMHO never be strongly-typed by default.


Probably.


 The best approach to have some reasonable
 type rules is to progressively strenghten the rules (as Zeev's RFC
 tried to do so, but he probably did two steps in one RFC and that's
 what people dislike about it?).


You think the best approach is to progressively and continually break
working code between versions? How is this approach acceptable ever?


 I think that PHP's type system would
 get to some equilibrium by this - people wanting stronger typing
 would tried to introduce it and people wanting weaker one would
 balance it and eventually there could be a point on which both sides
 could agree on.


No, they would never reach agreement.

I sincerely hope the Dual Mode RFC doesn't pass. I can't imagine the
 RFC being good for the userland developers in the long run.


Apologies again, but I think you don't really understand what is being
proposed in this RFC. Proponents of strict typing get exactly what they
want, they can develop their library or entire project in strict mode if
they want, and if someone wants to use this project or library, but
themselves want to use weak mode, _nothing breaks_.

Re: [PHP-DEV] [RFC] [VOTE] Vote open for reliable user-land CSPRNG

[Leigh]

On 15 March 2015 at 10:29, Matteo Beccati p...@beccati.com wrote:

 I want to vote yes, but naming is something that scares me a bit. Without
 any indication that it's CSPRNG, people might start using it even when
 unnecessary, and I'd be worried about potential negative effects, such as
 exhausting the entropy pool. It's probably more of a documentation problem,
 but we know many won't read the docs and a hint in the function name
 could help guiding users.


I wouldn't worry about exhausting the entropy pool, on systems like Linux
there is kind of a feedback system where data is mixed back into the pool
when you request data. You can pipe /dev/urandom into /dev/null for hours
and not suffer any problems.


 For example, it would be overkill to use random_int() to randomly pick the
 content of a boxes at each reload of a web page, but if what I need is a
 *random int*, then random_int() seems a far better choice than some obscure
 rand() or mt_rand().


Of course it would, but that's something that needs to be done through
education and via the manual. I understand the concern, but I'm not sure
how much I'll worry about it.

Or in the poker deck example, wouldn't it be enough just to seed mt_srand
 with a crypto-secure number to remove the biasing and using mt_rand to
 shuffle the deck?


The biasing comes from how the result is restricted to a certain range of
numbers, it's not related to the quality of the seed. We avoid that by
throwing away numbers that would give a biased result, and picking a new
number.

The poker deck example isn't a brilliant one, because the effects of
biasing become more apparent the closer you get to the maximum upper bound,
but it's still important to cater for the unlikely-but-possible scenarios.