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

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

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

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

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

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

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_

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Re: [PHP-DEV] Fwd: Monotonic Time

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

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

tually, 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;

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

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

Re: [PHP-DEV] Security issue handling

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

Re: [PHP-DEV] Security issue handling

tas, 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 securi

[PHP-DEV] Strict types indicator in backtraces

d opinions? Cheers, Leigh.

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

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

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

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

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

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

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

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

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

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

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 >

[PHP-DEV] Intention to move mcrypt to PECL

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

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

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

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 repeat

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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 follow

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

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

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

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

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

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

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

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

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

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-DEV] [RFC][VOTE] RNG fixes

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[PHP-DEV] [RFC] RNG fixes

but I have overlooked, please let me know so I can get them included. Regards, Leigh.

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

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

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

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.

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

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

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

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 >

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

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

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

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

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

Re: [PHP-DEV] HashDos protection

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

Re: [PHP-DEV] 7.0.0 release

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

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

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

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

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

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

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

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

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

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

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

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-DEV] Make sessions use php_random_bytes in 7.1

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)

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

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

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

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

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

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

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

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

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

Re: [PHP-DEV] PHP 7.1 Cryptography Projects

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

Re: [PHP-DEV] 7.0 Release Management

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

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

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

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

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

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

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,

Re: [PHP-DEV] 7.0 Release Management

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,

Re: [PHP-DEV] 7.0 Release Management

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

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

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

[PHP-DEV] 7.0 Release Management

? Cheers, Leigh.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1   2   3   4   >