Re: [PHP-DEV] password_verify() and unknown algos

On Wed, Jan 27, 2021 at 11:27 AM Benjamin Morel wrote: > Hi internals, > > I just spent some time debugging an authentication issue after upgrading > PHP, and realized that it was due to ext-sodium not being installed, so > password_verify() would always return false for argon2i hashes. > >

[PHP-DEV] [RFC] [Withdrawn] Adopt Code of Conduct

All, I've decided to withdraw the CoC RFC. There are many reasons for it, but there are a few points I want to make. As to the content of the RFC, when I initially proposed it, I selected the Contributor Covenant due to it being a well adopted standard. Several people raised objections to it,

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

David, On Mon, Jan 11, 2016 at 5:05 PM, David Zuelke <d...@heroku.com> wrote: > On 11.01.2016, at 12:31, Anthony Ferrara <ircmax...@gmail.com> wrote: > >> Actually, asking for proof and denying are the same thing. If they >> weren't, then why would you be asking

[PHP-DEV] Status Of CoC RFC: (WAS: Adopt Code of Conduct)

All, > If we want to deal with the reasons why people avoid internals, the let's go > and analyze the problem first ? I will start asking whether we really want > to attract newcomers. The question may sound ridiculous but I think we > don't, mostly because most people here see newcomers as just

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

Stas, On Mon, Jan 11, 2016 at 3:15 PM, Stanislav Malyshev wrote: > Hi! > >> I fail to understand how one can think that the CoC could be about >> censorship (which is basically what this comment says). > > I can explain you that very easily: there are known instances where

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

Stas, On Mon, Jan 11, 2016 at 11:00 AM, Stanislav Malyshev wrote: > Hi! > >> least hold ourselves to a level of mutual respect. Going out and >> calling someone a moron in public is not constructive nor respectful, >> and IMHO we as a project shouldn't sit back and blindly

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

Brandon, On Mon, Jan 11, 2016 at 8:47 AM, Brandon Savage wrote: >> >> At the same time, though, if someone is being maliciously hostile what >> great cover! A private email is not a PHP-Group managed resource, so no >> rules! Twitter, ha, no rules! Reddit? LOL like

Re: [PHP-DEV] PHP 7.1 - Argon2

+ Solar Designer On Mon, Jan 11, 2016 at 7:55 AM, Rouven Weßling wrote: > >> On 11 Jan 2016, at 13:27, Pierre Joye wrote: >> >> Hi, >> On Jan 11, 2016 4:12 PM, "Rouven Weßling" wrote: >> > >> > * Is there already a crypt

Re: [PHP-DEV] Re: Anonymous voting on wiki

Stas, On Sat, Jan 9, 2016 at 5:00 PM, Stanislav Malyshev wrote: > Hi! > >> This seems useful. I do wonder whether we should use by default for >> RFCs. It's interesting to see how different people vote, and knowing who > > I think we talked about it, and decided not to do

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

All, > I was not hesitant (or, let's maybe call it "intentionally procrastinating") > to post on this topic because I felt unsafe on this list or in the general > realm of the PHP community; I simply was in no mood to deal with a mob of > self-proclaimed-or-not "Social Justice Warriors" and

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

Sara, On Thu, Jan 7, 2016 at 8:16 PM, Sara Golemon wrote: > On Thu, Jan 7, 2016 at 2:51 PM, Zeev Suraski wrote: >> Having a CoC which is wider in scope and ratified by a voted RFC rather >> than an email on some mailing list sends a strong message. Having it in

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

Keith, On Fri, Jan 8, 2016 at 11:38 AM, D Keith Casey wrote: > On 1/7/16 11:52 PM, Larry Garfield wrote: >> >> On 01/07/2016 10:08 PM, Brian Moon wrote: Why not? The harassment has been nullified. >>> >>> I agree with your position on most of this, Paul.

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

Kevin, On Fri, Jan 8, 2016 at 10:39 AM, Kevin Smith <ke...@gohearsay.com> wrote: > > >> On Jan 8, 2016, at 9:09 AM, Anthony Ferrara <ircmax...@gmail.com> wrote: >> >> >> Simply look at the level of attacks that me and a few other committers >> hav

Re: [PHP-DEV] [RFC] Libsodium

Pierre, >> Even if we axe mcrypt and in with a net-gain of 0 extensions, you'd >> see it as a risk? > > Except that we already refused to kill mcrypt, and it is not like I > did not try to convince us to kill it. We decided not to kill it for 7.0. That doesn't mean it got a permanent buy... >>

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

Zeev, On Thu, Jan 7, 2016 at 3:50 PM, Zeev Suraski <z...@zend.com> wrote: >> -Original Message----- >> From: Anthony Ferrara [mailto:ircmax...@gmail.com] >> Sent: Thursday, January 07, 2016 8:15 PM >> To: internals@lists.php.net >> Subject: [PHP-DEV] Re:

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

Stas, On Tue, Jan 5, 2016 at 11:57 PM, Stanislav Malyshev wrote: > Hi! > >> In response to significant feedback here and elsewhere, I have >> expanded the text of the RFC significantly. It now includes the text >> of the Contributor Covenant 1.3.0 as well as including

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

All, On Wed, Jan 6, 2016 at 3:43 PM, François Laupretre wrote: > Le 06/01/2016 20:38, Ryan Pallas a écrit : >> >> >> I agree, a conflict resolution document *and team* seems infinitely >> better. >> This team's job is to resolve things quietly and without further incident, >>

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

All, On Mon, Jan 4, 2016 at 4:06 PM, Anthony Ferrara <ircmax...@gmail.com> 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-cond

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

Rowan, On Tue, Jan 5, 2016 at 2:16 PM, Rowan Collins wrote: > Paul M. Jones wrote on 05/01/2016 16:03: >> >> It's a*political* action designed with a*political* intent > > > Please stop assuming that everybody has a hidden agenda at odds with their > public statements,

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

Larry >> I'll chime in on this, since you and I had a quite pleasant and >> productive conversation last night. I believe we agreed that the >> original draft was over-focused on punitive measures and not enough on >> low-impact mediation. >> >> I imagine, because I love all you guys (and gals),

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

Zeev, On Tue, Jan 5, 2016 at 3:10 PM, Zeev Suraski <z...@zend.com> wrote: >> -Original Message----- >> From: Anthony Ferrara [mailto:ircmax...@gmail.com] >> Sent: Tuesday, January 05, 2016 6:16 PM >> To: internals@lists.php.net >> Subject: [PHP-DEV] Re:

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

Chase, On Tue, Jan 5, 2016 at 4:51 PM, Chase Peeler wrote: > While overall I tend to agree with Paul on the concept of a CoC, I don't > think that precludes the ability to offer suggestions. It's to everyone's > advantage to make sure that if we do adopt a CoC, we adopt

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

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 -- PHP Internals - PHP Runtime

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

Adam, On Mon, Jan 4, 2016 at 4:41 PM, Adam Harvey <ahar...@php.net> wrote: > On 4 January 2016 at 13:06, Anthony Ferrara <ircmax...@gmail.com> wrote: >> I have created a new RFC for the PHP Project to adopt the Contributor >> Covenant as the official Code of Conduct

Re: [PHP-DEV] RFC: PHP 5.6 Support Timeline

Zeev, On Tue, Dec 8, 2015 at 10:14 AM, Zeev Suraski wrote: > Following the initial discussion, I prepared an RFC that proposes to extend > the support periods for PHP 5.6: > > > > https://wiki.php.net/rfc/php56timeline > > > > Thanks to Ferenc Kovacs and David Zuelke for reviewing

Re: [PHP-DEV] RFC: PHP 5.6 Support Timeline

Zeev, On Tue, Dec 8, 2015 at 1:15 PM, Zeev Suraski <z...@zend.com> wrote: >> -Original Message----- >> From: Anthony Ferrara [mailto:ircmax...@gmail.com] >> Sent: Tuesday, December 08, 2015 6:09 PM >> To: Zeev Suraski >> Cc: PHP internals >> S

Re: [PHP-DEV] Namespaces

Scott, On Fri, Dec 4, 2015 at 11:26 AM, Scott Arciszewski wrote: > Hi, > > It has been brought to my attention that my consistent use of \ prefixing > of global functions is an eyesore, but I've got a simple little PoC that > shows why I do it, and now I'm wondering if the

Re: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

Sebastian, On Tue, Nov 24, 2015 at 10:10 AM, Sebastian Bergmann wrote: > The following is currently valid PHP 7 code > >function a(\int $i) {} > > Is it intentional that the \ in front of the "int" is allowed? IMHO, this > confusing notation must not be allowed.

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

Zeev and all, On Mon, Nov 23, 2015 at 9:05 AM, Zeev Suraski wrote: > > >> On 23 בנוב׳ 2015, at 14:04, Joe Watkins wrote: >> >> >> No one is expecting 0.0 or any version to be bug free, but the simplicity of >> the fix says nothing about the seriousness of

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

Zeev, On Mon, Nov 23, 2015 at 9:43 AM, Zeev Suraski <z...@zend.com> wrote: > > >> On 23 בנוב׳ 2015, at 15:21, Anthony Ferrara <ircmax...@gmail.com> wrote: >> >> Zeev and all, >> >>> On Mon, Nov 23, 2015 at 9:05 AM, Zeev Suraski <z...

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

Zeev, On Sat, Nov 21, 2015 at 11:52 PM, Zeev Suraski <z...@zend.com> wrote: > >> On 22 בנוב׳ 2015, at 0:47, Anthony Ferrara <ircmax...@gmail.com> wrote: >> >> I think this is significant enough to be a blocker to gold and that we >> should fix it prior

[PHP-DEV] INDRECT in arrays causes count() to become unpredictable

All, It appears that in our efforts to optimize PHP 7 we've introduced an inconsistency into array handling. This is demonstrated by this script: https://3v4l.org/hVcAB $a = 1; unset($a); var_dump(count($GLOBALS), $GLOBALS); The result is that the count doesn't match the contents of the array.

Re: [PHP-DEV] Immutable modifier

Chris, On Mon, Nov 16, 2015 at 4:15 AM, Chris Riley wrote: > Hi, > > There has been a lot of interest recently (eg psr-7) in immutable data. I'm > considering putting an RFC together to add language support for immutables: > > immutable class Foo { > public $bar; > public

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

Tom, > 3. arc4random puts a generator in the user process. > > This is much more controversial. Some people (Anthony F. for one and myself > until recently) argue that a generator algorithm in the user process > degrades security. It must in any case be downstream of the kernel source > and

Re: [PHP-DEV] Password_hash salt generation refactor

All, On Tue, Oct 20, 2015 at 11:35 PM, Anatol Belski <anatol@belski.net> wrote: > Hi Anthony, > >> -Original Message- >> From: Anthony Ferrara [mailto:ircmax...@gmail.com] >> Sent: Monday, October 19, 2015 1:00 AM >> To: internals@lists.php.net >

Re: [PHP-DEV] PHP 7.0.0RC6 is available

Shouldn't gold wait for fixes on critical and reproducible bugs? Like https://bugs.php.net/bug.php?id=70805 which is currently blocking Drupal 8 from supporting PHP 7.0... On Thu, Oct 29, 2015 at 8:15 AM, wrote: > Hi, > > The sixth release candidate for 7.0.0 was just released and

Re: [PHP-DEV] [VOTE] Void Return Type RFC

Dan, On Thu, Oct 29, 2015 at 9:22 AM, Dan Ackroyd wrote: > Pedro, your email client snipped off the internals CC > > On 29 October 2015 at 13:11, Pedro Cordeiro wrote: >> If that callback is actually a void function, then using its return value IS

[PHP-DEV] Password_hash salt generation refactor

All, With PHP 7 comes random_bytes and random_int. This duplicates some of the logic internally that password_hash uses to generate its salt. I would like to refactor this to unify generation. I've opened a PR against master: https://github.com/php/php-src/pull/1585 I don't feel comfortable

Re: [PHP-DEV] Re: [RFC] Void Return Type (v0.2, reöpening)

Robert, > You write in your RFC "others do allow void functions in expressions, just as > PHP does, by making them implicitly return > some unit type." > You mentioned TypeScript -- unit type = null -- ActionScript -- unit type = > undefined -- and Swift -- unit type = empty > tuple, ergo (). >

Re: [PHP-DEV] Port random_bytes to PHP 5

Tom, On Tue, Oct 13, 2015 at 10:17 AM, Tom Worster wrote: > On 10/12/15 10:53 PM, Larry Garfield wrote: >> >> On 10/12/2015 07:29 PM, Tom Worster wrote: >>> >>> Could we regard random_bytes() as a security patch rather than a new >>> feature and therefore port it to PHP 5? >>>

Re: [PHP-DEV] Scalar type hints and scalar type name aliases causeconfuson

All, On Tue, Oct 13, 2015 at 9:56 AM, Rowan Collins wrote: > Andrea Faulds wrote on 13/10/2015 12:00: >> >> Hi Michael, >> >> Michael Wallner wrote: >>> >>> On 12/10/15 21:23, Andrea Faulds wrote: Even if we can't reserve the names, I hope we can do the two

Re: [PHP-DEV] Remove name mangling? (when creating variables from external sources)

Hey, On Tue, Oct 6, 2015 at 4:38 PM, Bishop Bettini wrote: > Hi! > > Currently dots and spaces are converted to underscores when pulling them in > from HTML: > > > > > > > > > > Ostensibly[1], names were mangled to support

Re: [PHP-DEV] Arrow function expressions in PHP

Nikita and all, On Thu, Oct 1, 2015 at 10:58 AM, Nikita Nefedov wrote: > On Thu, 01 Oct 2015 15:33:51 +0300, Rowan Collins > wrote: > >> That's not how Rasmus expressed it >> [http://marc.info/?l=php-internals=144107616411299=2]: >> >> > I made a

Re: [PHP-DEV] PHP 7.0.0RC4 is available

Congrats!!! Thank you so much for what you are doing! Keep up the awesome work! On Thu, Oct 1, 2015 at 9:02 AM, wrote: > Hi, > > The fourth release candidate for 7.0.0 was just released and can be > downloaded from: > > https://downloads.php.net/~ab/ > > The Windows binaries

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

Thomas, On Tue, Sep 29, 2015 at 11:22 AM, Thomas Hruska wrote: > On 9/29/2015 6:52 AM, Joe Watkins wrote: >> >> We shouldn't reserve words on a whim ... >> >> async/await doesn't solve any problems for multithreaded programming, at >> all ... it solves problems for

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

Stas, On Thu, Sep 24, 2015 at 2:21 PM, Stanislav Malyshev wrote: > Hi! > >> How does one then address that this RFC only covers a subset of >> Hacklang functionality when having the same operator? > > Why one should address it? PHP is a different language, and we are under >

Re: [PHP-DEV] [RFC] [VOTE] Short Closures

Dmitry, On Tue, Sep 22, 2015 at 2:05 PM, Dmitry Stogov wrote: > On Tue, Sep 22, 2015 at 7:01 PM, Bob Weinand wrote: > >> >> > Am 22.09.2015 um 17:36 schrieb Dmitry Stogov : >> > >> > On Tue, Sep 22, 2015 at 4:54 PM, Joe Watkins

Re: [PHP-DEV] [RFC] [VOTE] Short Closures

Dmitry, On Tue, Sep 22, 2015 at 3:19 PM, Dmitry Stogov <dmi...@zend.com> wrote: > > > On Tue, Sep 22, 2015 at 9:20 PM, Anthony Ferrara <ircmax...@gmail.com> > wrote: >> >> Dmitry, >> >> On Tue, Sep 22, 2015 at 2:05 PM, Dmitry Stogov <dmi...@ze

Re: [PHP-DEV] Let's discuss enums!

Levi et al, On Fri, Sep 18, 2015 at 10:11 AM, Levi Morrison wrote: > On Thu, Sep 17, 2015 at 5:52 PM, John Bafford wrote: >> On Sep 17, 2015, at 19:16, Bob Weinand wrote: >>> Am 18.09.2015 um 01:06 schrieb Rowan Collins

Re: [PHP-DEV] Make strict mode more strict?

Yasuo, On Wed, Sep 16, 2015 at 6:10 PM, Yasuo Ohgaki wrote: > Hi all, > > PHP 7 has strict_types mode for function parameters/return values and > these are binded to certain type strictly. > https://wiki.php.net/rfc/scalar_type_hints_v5 > > Why not make strict_types mode more

Re: [PHP-DEV] taint

All, On Tue, Sep 15, 2015 at 11:15 AM, Arvids Godjuks wrote: > I fully support your effort to get this into the PHP to be part of core > extensions, or at least one of those that keep up with the language > releases. > This is a very good tool to have, and you can

Re: [PHP-DEV] Re: [RFC] [Discussion] Short Closures

Rowan On Mon, Sep 7, 2015 at 10:14 PM, Rowan Collins wrote: > Andrea Faulds wrote on 06/09/2015 22:54: >> >> Also, it would be nice if PHP and Hack don't diverge when implementing the >> same features, unless there's a particularly good reason... it's not very >> kind to

[PHP-DEV] Re: [RFC] [Vote] Random Functions Throwing Exceptions in PHP 7.0.0

Voting is now closed. The proposal is accepted 28:2. I will merge PR #1379 to master tomorrow (to give time for a final code-review). https://github.com/php/php-src/pull/1397 Thanks all! Anthony On Sun, Aug 30, 2015 at 6:54 PM, Anthony Ferrara <ircmax...@gmail.com> wrote: > All, &

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

Pavel On Tue, Sep 1, 2015 at 4:32 AM, Pavel Kouřil wrote: > On Mon, Aug 31, 2015 at 9:29 PM, Bob Weinand wrote: >> I had this RFC in draft since some time, but delayed it due to all the >> ongoing PHP 7 discussions. Also we have no master branch to

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

Stas, On Mon, Aug 31, 2015 at 11:46 PM, Stanislav Malyshev wrote: > Hi! > >> Here it is very obvious that we want to import a variable. Especially, I >> wonder how >> $array = array_map(function ($x) use ($y) { return $x + $y; }, $array); >> is making such simple

[PHP-DEV] [RFC] [Vote] Random Functions Throwing Exceptions in PHP 7.0.0

Try number 2, when I sent this yesterday it didn't seem to come through. On Aug 30, 2015 6:54 PM, Anthony Ferrara ircmax...@gmail.com wrote: All, I have opened voting for the Random Functions Throwing Exceptions RFC as the required week of discussion time has passed with minimal discussion

[PHP-DEV] [RFC] [Vote] Random Functions Throwing Exceptions in PHP 7.0.0

All, I have opened voting for the Random Functions Throwing Exceptions RFC as the required week of discussion time has passed with minimal discussion. https://wiki.php.net/rfc/random-function-exceptions Voting will close at 07:00 UTC on Sunday, September 6 (1 week from today). Anthony -- PHP

[PHP-DEV] [RFC] [Discuss] Random Functions Throwing Exceptions in PHP 7.0.0

All, I am putting a simple RFC up for discussion to make random_* throw exceptions on failure in order to ensure we fail-closed. https://wiki.php.net/rfc/random-function-exceptions Considering this topic has already been discussed, I intend to open voting on this as soon as allowable. Given the

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

Anatol, On Sat, Aug 22, 2015 at 10:34 AM, Anatol Belski anatol@belski.net wrote: Hi Anthony, -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Saturday, August 22, 2015 4:44 AM To: Pierre Joye pierre@gmail.com Cc: Anatol Belski anatol

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

Pierre On Aug 21, 2015 22:33, Pierre Joye pierre@gmail.com wrote: On Sat, Aug 22, 2015 at 9:16 AM, Anthony Ferrara ircmax...@gmail.com wrote: If that's what it will take I will happily draft one tomorrow morning. But if the RMs are against it, I will respect that as well. Hence

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

Anatol, On Aug 21, 2015 8:10 PM, Anatol Belski anatol@belski.net wrote: Hi, -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Friday, August 21, 2015 3:37 PM To: Scott Arciszewski sc...@paragonie.com Cc: Pierre Joye pierre@gmail.com; Trevor

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

Pierre On Aug 21, 2015 22:01, Pierre Joye pierre@gmail.com wrote: On Sat, Aug 22, 2015 at 8:43 AM, Anthony Ferrara ircmax...@gmail.com wrote: Anatol, On Aug 21, 2015 8:10 PM, Anatol Belski anatol@belski.net wrote: Hi, -Original Message- From: Anthony Ferrara

Re: [PHP-DEV] set_exception_handler catches all Throwables

Stas and all, On Wed, Aug 19, 2015 at 2:45 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! Actually, I don't call this intended. This is just as much as a BC break as the original implementation where Errors where also Exceptions. IMO, set_exception_handler() should be changed - with

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

Matt, You are of course welcome to disagree with the overwhelming body of security advice that parameterized queries are the correct, secure way to prevent SQL injection. In that case, you only need to not enable this feature. This feature is off-by-default, and only attempts to help secure

Re: [PHP-DEV] PHP 7.1 Cryptography Projects

All, How about Anthony Ferrara (a board member for the Password Hashing Contest)? For the record, my only involvement with the PHC is as a passive observer. I am not on the board nor have I been actively involved. Anthony -- PHP Internals - PHP Runtime Development Mailing List

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

All, On Wed, Aug 5, 2015 at 10:40 AM, Julien Pauli jpa...@php.net wrote: On Tue, Jul 28, 2015 at 7:33 PM, Matt Tait matt.t...@gmail.com wrote: Hi all, I've written an RFC (and PoC) about automatic detection and blocking of SQL injection vulnerabilities directly from inside PHP via automated

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

Matt, To be clear: this feature does not track taint through escape functions, regular expression filters, ctype_filters and the like by design. Security best-practice and more than a decade of security consulting experience show that developers who rely on filters and escaping rarely manage

Re: [PHP-DEV] PHP 7.1 Cryptography Projects

Lauri, On Tue, Aug 4, 2015 at 9:12 AM, Lauri Kenttä lauri.ken...@gmail.com wrote: On 2015-08-04 14:54, Scott Arciszewski wrote: we do not allow secure modes I hope that was a typo... ;) Indeed, it was not. The concept for this (I've been working with Scott on it) is that this should be a

Re: [PHP-DEV] Exposing object handles to userland

Anatol, On Mon, Aug 3, 2015 at 10:38 AM, Anatol Belski anatol@belski.net wrote: Hi Nicolas, -Original Message- From: nicolas.gre...@gmail.com [mailto:nicolas.gre...@gmail.com] On Behalf Of Nicolas Grekas Sent: Monday, August 3, 2015 1:29 PM To: Rowan Collins

Re: [PHP-DEV] PHP 7.1 Cryptography Projects

Scott, On Mon, Aug 3, 2015 at 4:54 PM, 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

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

Ferenc, On Jul 31, 2015 6:34 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Jul 14, 2015 at 11:04 PM, Sammy Kaye Powers m...@sammyk.me wrote: Hello lovely PHP nerds, There are two open PR's for PHP7 to modify the behavior of the CSPRNG's: https://github.com/php/php-src/pull/1397 (main

Re: [PHP-DEV] Exposing object handles to userland

Julien, On Fri, Jul 31, 2015 at 10:23 AM, Julien Pauli jpa...@php.net wrote: Hi people. I've been pinged many times to add a new spl_object_id() function to PHP, that would return the internal object handle of an object. Today, spl_object_hash() partially allows that, but adds many

Re: [PHP-DEV] Exposing object handles to userland

Nicolas, On Fri, Jul 31, 2015 at 2:24 PM, Nicolas Grekas nicolas.grekas+...@gmail.com wrote: Anthony's argument about exposing the mem layout is crucial, though. Yes it is! The patch I attached un-xors only the part for the object's handle. The memory pointer is kept xored. Just checked

Re: [PHP-DEV] Disabling External Entities in libxml By Default

Stas, On Thu, Jul 30, 2015 at 2:57 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! The problem here is that imagine the following: I think if we separate the loading the initial file (i.e., staring point of the XML parser) and the loading the entities from that file (which is not

[PHP-DEV] Disabling External Entities in libxml By Default

All, I wanted to float an idea by you for PHP 7 (or 7.1 depending on the RM's feedback). Currently, PHP by default is vulnerable to XXE attacks: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing To bypass this, you need to turn off external entity loading:

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

Rowan, This is certainly some people's concern, but Anatol has raised a subtly different consistency-related point, which is this: Since we have no policy for what kinds of Throwable should be emitted in what circumstance, throwing anything in this function sets a precedent which will have

Re: [PHP-DEV] json_decode/encode should return full precision values by default

Yasuo, On Sun, Jul 26, 2015 at 4:20 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Jakub, On Mon, Jul 27, 2015 at 3:32 AM, Jakub Zelenka bu...@php.net wrote: I don't think that this is a bug. Your example is also completely unrelated to json because the place when the value is rounded is

Re: [PHP-DEV] Optimizing php_html_entities()

On Tue, Jun 23, 2015 at 10:33 AM, Xinchen Hui larue...@php.net wrote: Hey: On Tue, Jun 23, 2015 at 7:37 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, I'm trying to optimize php_html_entities(). Since htmlspecialchars()/htmlentities() are sensitive function, I would like to ask

Re: [PHP-DEV] Optimizing php_html_entities()

Yasuo, IMHO, escape/unescape/encode/decode/conversion function is better to accept any types. HTML template may be separated script, but database code etc may not. Writing code like ?php declare(strict_types=1); $sql = 'SELECT * FROM '. pg_escape_identifier((string)$table). ' WHERE id

Re: [PHP-DEV] RFC - making the Exception class abstract

Kevin, On Wed, Jun 17, 2015 at 4:41 PM, Kevin Bradwick kevinbradw...@gmail.com wrote: Hello! This is my first post to the internals list so please forgive me if I have not followed the rules precisely! I've had an idea to improve how developers use exceptions within PHP. I'd like to add an

Re: [PHP-DEV] [RFC] [PHP 7.1] libsodium

Scott, On Wed, May 20, 2015 at 9:15 PM, Scott Arciszewski sc...@paragonie.com wrote: Hi Internals Team, I'm sure everyone is really focused (and excited) for PHP 7.0.0 later this year, and many of you might not want to discuss what 7.1.x looks like yet. The current state of cryptography in

Re: [PHP-DEV] Branching off PHP7 and electing RMs

a week passed and the Kalle Anatol option is winning unanimously after 23 votes so far. should we wait another week or would be okay to close the votes and announce the RMs so that we can start working on preparing the first alpha? That seems reasonable to me. There was no real objection

Re: [PHP-DEV] password_hash() best practices

Leszek, On Thu, May 7, 2015 at 2:11 AM, Leszek Krupinski leafn...@gmail.com wrote: On Wed, May 6, 2015 at 4:00 PM, Nikita Popov nikita@gmail.com wrote: It should be further noted that there is no standardized crypt() format for PBKDF2 and password_hash() is a crypt-compatible API. As such

Re: [PHP-DEV] Add support $object::class

On Mon, Apr 27, 2015 at 7:18 AM, S.A.N ua.san.a...@gmail.com wrote: Now this code causes an error PHP 5-7. PHP Parse: Syntax error, unexpected 'class' (T_CLASS), expecting identifier (T_STRING) or variable (T_VARIABLE) or '{' or '$' Do not want to use get_class($object) Why not?

Re: [PHP-DEV] RFC: spl_autoload_register() should provide kind of entity to load

Georges, On Sat, Apr 18, 2015 at 10:24 AM, georges geol...@gmail.com wrote: Hi php internals, Currently spl_autoload_register() pass the name of the class entity to the first *Callable* argument, but there is now way (as i far i know) to know what kind of entity we're looking for. -Class ?

Re: [PHP-DEV] Concern around growing complexity in engine - hash table specifically

, 2015 at 9:57 PM, Anthony Ferrara ircmax...@gmail.com wrote: All, I spent a little bit of time today trying to debug an issue with 7 that Drupal 8 was facing, specifically regarding an array index not behaving correctly ($array[key] returned null, even though the key existed in the hash

Re: [PHP-DEV] password_hash() deprecate salt option - thoughts?

I gave it some additional time in case others raised concern. I have since merged the deprecation of the salt option to password_hash() Thanks! Anthony On Wed, Apr 1, 2015 at 2:26 PM, Anthony Ferrara ircmax...@gmail.com wrote: All, I've added a PR for this: https://github.com/php/php-src

RE: [PHP-DEV] Concern around growing complexity in engine - hash table specifically

Fancois, On Apr 9, 2015 10:16 AM, François Laupretre franc...@php.net wrote: De : Anthony Ferrara [mailto:ircmax...@gmail.com] If we were using a pure abstraction (only accessing the hash table information through the public API), then fine because it's isolated. However, many

Re: [PHP-DEV] Exception message cleanup

Nikita, On Apr 9, 2015 8:56 AM, Nikita Popov nikita@gmail.com wrote: On Thu, Apr 9, 2015 at 12:33 PM, Niklas Keller m...@kelunik.com wrote: Hi Nikita, I like the new display format, but there's one thing I miss. If you replace the exception name for warnings and fatals, how does a

Re: [PHP-DEV] Concern around growing complexity in engine - hash table specifically

Andi, On Tue, Apr 7, 2015 at 8:52 PM, Andi Gutmans a...@zend.com wrote: On Fri, Apr 3, 2015 at 11:57 AM, Anthony Ferrara ircmax...@gmail.com wrote: All, I spent a little bit of time today trying to debug an issue with 7 that Drupal 8 was facing, specifically regarding an array index

[PHP-DEV] Concern around growing complexity in engine - hash table specifically

All, I spent a little bit of time today trying to debug an issue with 7 that Drupal 8 was facing, specifically regarding an array index not behaving correctly ($array[key] returned null, even though the key existed in the hash table). I noticed that the hash table implementation has gotten

Re: [PHP-DEV] password_hash() deprecate salt option - thoughts?

All, I've added a PR for this: https://github.com/php/php-src/pull/1213 Please review the implementation and the wording (as well as the behavior). I plan on merging this on Friday if there is no objection (as it seems the support has already been unanimous with no hesitation). Thanks!

Re: [PHP-DEV] Overwrite return type-hint into a more specific one

Marc, On Wed, Apr 1, 2015 at 2:46 PM, Marc Bennewitz dev@mabe.berlin wrote: Hi internals, On experimenting with return type-hints I noted an inconsistency on overwriting an existing hint to a more specific one. On adding a non existing return type-hint on overwrite it's fine but it's

Re: [PHP-DEV] Naming of 'weak' type hints

Pavel, Hello, I would definitely stick with weak; it is common naming used across many languages and textbooks. Also, why is the strongly typed mode named strict anyways? If anything should change, it should be strict to strong, so PHP doesn't look like a special snowflake. Strong has a

[PHP-DEV] password_hash() deprecate salt option - thoughts?

All, Ever since we introduced password_hash() in 5.5, I've been watching its usage as much as possible. I've setup google alerts and such, as well as auditing implementations I've found on github to try to understand how it's used. One thing has become abundantly clear to me: the salt option is

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

All, Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Thank you. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

[PHP-DEV] Voting irregularities

All, I ran some numbers on the current votes of the dual-mode vote right now. There were a number of voters that I didn't recognize. So I decided to pull some stats. The following voters never voted before the dual-mode RFC went up: dom - no eliw - no kguest - yes kk - no nohn - no oliver - yes

Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types

Zeev, On Sun, Mar 15, 2015 at 3:07 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Pádraic Brady [mailto:padraic.br...@gmail.com] Sent: Sunday, March 15, 2015 9:00 PM To: Zeev Suraski Cc: Bob Weinand; PHP Internals Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar

Re: [PHP-DEV] [RFC] Basic Scalar Types

Zeev, Zeev, allow me to understand how this goes. Bob's discussions on the RFC started 2 days ago. Based on the current rules, the RFC can only go to vote after 2 weeks. That means in 12 days starting now. So we are either violating the RFC rules by pushing the vote tomorrow or we're

Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types

Zeev, Thus, I deny your request and strongly urge you to *not* fork my RFC. That would be sabotaging of Anthony's and my RFC. I won't tolerate that. Anthony welcomed competing RFCs, and in fact proposed it. I don't see how it would be sabotaging your RFC - when in fact it gives it a

  1   2   3   4   5   6   7   >