[PHP-DEV] Re: Including "Disable the ability to use concrete types in PHAR metadata" in PHP 8.0?
Hi! > https://bugs.php.net/bug.php?id=76774 has been open since 2018-08-21. > > That ticket proposes the following: > >> I propose that we disable the ability to have concrete types included in the >> serialized metadata by >> providing an empty classlist to the unserialize call in the PHAR package. >> This will support the real cases we see in the wild of metadata usage which >> is only array key values. I think it's a good idea. I am a little bit worried that somebody somewhere may be using phars with object data, and it'd be nice to create some way for such people to still use these phars, but by default I think no complex objects is a good idea. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Including "Disable the ability to use concrete types in PHAR metadata" in PHP 8.0?
Hi internals, https://bugs.php.net/bug.php?id=76774 has been open since 2018-08-21. That ticket proposes the following: > I propose that we disable the ability to have concrete types included in the > serialized metadata by > providing an empty classlist to the unserialize call in the PHAR package. > This will support the real cases we see in the wild of metadata usage which > is only array key values. A major change such as PHP 8.0 seems like a good time to disable this. (but it seems safe enough for any minor version) Various blog posts have been written explaining the resulting vulnerabilities, such as https://www.ixiacom.com/company/blog/exploiting-php-phar-deserialization-vulnerabilities-part-1 This change was previously proposed in https://externals.io/message/105271#105303 > Bishop Bettini wrote, > > I agree that $allowed_classes is a partial fix. > But is it not better to incrementally add defensive layers? > > I'll get to the immediate mitigation after I finish my phar fuzzing work, > unless somebody beats me to it. I'm in favor of adding the defensive layer, and could probably implement the immediate mitigation if needed. Thoughts on whether this needs an RFC? Has anything changed since that email thread? There seemed to be some debate over implementation details, but most responses considered the existing unserialization behavior problematic. - If it did, this may need to start less than two weeks after finishing an RFC, due to the feature freeze in august 8th. I assume the limitation of not allowing any objects (i.e. $allowed_classes=[]) for metadata would consistently affect getMetadata() and anything using the phar stream wrapper for a phar file. Emitting an E_WARNING may be helpful but not absolutely necessary if an object is seen anywhere in the data passed to Phar->setMetadata(). Thanks, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] FFI Improvements: Consistency and soliving some problems
Hi all! I would like to start discussion about the «FFI Improvements» RFC. At the moment, I do not have the right to create wiki page, so I post it on the github: https://github.com/SerafimArts/php-rfcs/blob/ffi-improvements/rfcs/-ffi-improvements.md The proposal: - Contains improvements regarding the harmonization of supported FFI directives («define FFI_XXX») in different operating modes (cdef and load). - And he suggests solving the problem of the inability to work with some types of libraries that contain loading of other libraries. In addition, I want to add that I am not a C developer, and I understand that this reduces the chances of adopting this RFC. However, I think that the proposal is useful and if approved, someone will help to implement it.
[PHP-DEV] Re: [RFC] [VOTE] Make constructors and destructors return void
Hey internals, I have updated the RFC with 2 changes: 1. Made the RFC target PHP 9.0 for enforcing `void` rules implicitly. 2. Added a secondary vote for allowing explicit `void` return type declaration. I will be opening the vote again on Wednesday (July 8th). Best regards, Benas On Fri, 3 Jul 2020 at 00:12, Benas IML wrote: > > Hey internals, > > I have opened the voting for the RFC, let's hope everything is going > to be smooth :). If you have any other questions, let me know! > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > > Best regards, > Benas Seliuginas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Strict operators directive
On Mon, Jul 6, 2020 at 6:33 PM Benjamin Eberlei wrote: > > > On Mon, Jul 6, 2020 at 5:27 PM Arnold Daniels < > arnold.adaniels...@gmail.com> wrote: > >> Hi all, >> >> I'd like to start the discussion of the "Strict operators directive" RFC >> version 1.5. This RFC proposes a new directive strict_operators, which >> limits the type juggling done by operators to avoid unexpected results. >> >> https://wiki.php.net/rfc/strict_operators >> >> There are some significant changes from the previous version. >> strict_operators no longer has cases where it changes the outcome of an >> operation. To achieve this the following changes are made to the RFC >> >> * All comparison operators, besides `===` and `!==`, only accept `int` >> and `float` operands. For any other type a `TypeError` is thrown. This >> includes `==` and `!=`. >> > > what about DateTime and other objects overwriting comparison operators? > (GMP, ...) How would this proposal affect future proposals that expose > comparisons to userland (see for example the operator overloading RFC). > Custom compare handlers of objects (like DateTime and GMP) will be applied regardless of strict_operators. The ZEND_COMPARE_OBJECTS_FALLBACK macro will throw a TypeError if two objects are compared with different handlers. Converting an int to GMP is a widening primitive conversion and therefore allowed. I will modify the GMP compare handler as part of this RFC to throw a TypeError if the other operand isn't an 'int' or GMP object. Future proposals for userland custom comparisons should preferably adhere to the stricter rules for type conversion this RFC suggests, regardless of the strict_operators directive. In that case, it shouldn't be an issue to allow such objects as operands of overloaded operators. > > * The `switch` statement is not affected. >> > >> For frequently asked questions please see >> https://wiki.php.net/rfc/strict_operators/faq. >> > > Honestly PHP comparisons are already complex enough, introducing a second > set of rules that are just as complex seems like a risky proposal to me. > PHP comparisons are currently very complex. This RFC attempts to reduce/eliminate that complexity. Can you explain why the rules are still too complex and perhaps how they can be simplified more? >> [Arnold Daniels - Chat @ Spike]( >> https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=l1bam) >> [l1bam] > >
Re: [PHP-DEV] [RFC][DISCUSSION] Strict operators directive
On Mon, Jul 6, 2020 at 6:22 PM Marco Pivetta wrote: > Hey Arnold, > > Perhaps it makes sense for <=> to still operate with other types, as long > as they are uniform? Specifically: > > * error: 1 <=> "1" > * ok: "a" <=> "b" > * ok: true <=> false > Using `==`, `!=`, and `<=>` with string operands can lead to unexpected results because the operation differs when both operands are numeric strings. Instead `strcmp` or `Collator::compare()` should be used. See https://wiki.php.net/rfc/strict_operators#numeric_string_comparison Boolean operands could be allowed but that has limited use. Only allowing int or float is much clearer. > Similar for sorting: I use <=> to differentiate multi-dimensional arrays: > perhaps it should error if the array structure differs? > Some functionality concerning comparing objects and arrays is lost with strict_operators unfortunately. The RFC reduces complexity by throwing an error purely based on the type of operands and not based on the value of the operands. Alternatives where `==` and `!=` are supported for all types, are as complex as the comparison rules without strict_operators and/or result in cases where the outcome of an operation is changed based on the directive. > The rest of the proposal makes a lot of sense to me. > Thanks. > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > > > On Mon, Jul 6, 2020 at 5:27 PM Arnold Daniels < > arnold.adaniels...@gmail.com> wrote: > >> Hi all, >> >> I'd like to start the discussion of the "Strict operators directive" RFC >> version 1.5. This RFC proposes a new directive strict_operators, which >> limits the type juggling done by operators to avoid unexpected results. >> >> https://wiki.php.net/rfc/strict_operators >> >> There are some significant changes from the previous version. >> strict_operators no longer has cases where it changes the outcome of an >> operation. To achieve this the following changes are made to the RFC >> >> * All comparison operators, besides `===` and `!==`, only accept `int` >> and `float` operands. For any other type a `TypeError` is thrown. This >> includes `==` and `!=`. >> * The `switch` statement is not affected. >> >> For frequently asked questions please see >> https://wiki.php.net/rfc/strict_operators/faq. >> >> [Arnold Daniels - Chat @ Spike]( >> https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=l1bam) >> [l1bam] > >
Re: [PHP-DEV] Proposal: A way for classes to define a response to any primitive type cast
Hey Josh,
Similar proposals were raised recently for `__toArray()`: see
https://externals.io/message/108369#108369
I'd endorse avoiding object-to- casts via cast operations: they are
a good source of bugs.
My rationale for the discouragement of magic cast methods is explained with
some code examples at
https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On Mon, Jul 6, 2020 at 4:17 PM Josh Bruce wrote:
> Apologies, first time, still learning and have no historical context -
> timing is what it is.
>
> Proposal type: Concept
>
> Implementer: Unknown, fallback to me after slow learning
>
> Presumed simple implementation as the pattern should already be in place:
>
> Cast of (string) -> __toString() - already implemented
>
> Cast of (bool) -> __toBool()
>
> Cast of (int) -> __toInt()
>
> Cast of (object) -> __toObject()
>
> …and so on.
>
> Alternative implementation using an interface:
>
> \CastableTo{type}
>
> Extreme implementation:
>
> Make both of the previous available.
>
> Known unknowns:
>
> - Level of interest in something like this in the PHP community outside of
> one upvote on a Stackoverflow question I submitted:
> https://stackoverflow.com/questions/62747837/php-7-tostring-or-other-interface-for-boolean-values
> <
> https://stackoverflow.com/questions/62747837/php-7-tostring-or-other-interface-for-boolean-values
> >
> - Whether this conversation or proposal has already occurred.
> - The historical conversation leading to the creation of the __toString()
> method (and stopping there).
> - The current conversation around using magic methods in general and
> specifically when defining a cast response.
> - Enough details on PHP internal development to implement myself (this is
> the first time in 20 years I felt I couldn’t comfortably accomplish what I
> wanted to, thanks for that).
> - What potential collisions could occur if someone (me) wanted to
> implement all possibilities in a single class.
> - Right now __toBool() would be of the most personal benefit - if proposal
> is converted to an RFC, would it be better (faster/smoother) to do one RFC
> for all the cast possibilities - or to have an RFC for each cast separately?
>
> Thank you for the consideration, information, and feedback.
>
> Cheers,
> Josh
>
> ps. Also, apologies again for walking into a new space on a mission, not
> my normal approach.
>
> pps. The primary project inspiring the proposal:
> https://github.com/8fold/php-shoop
>
>
>
Re: [PHP-DEV] [RFC][DISCUSSION] Strict operators directive
On Mon, Jul 6, 2020 at 5:27 PM Arnold Daniels wrote: > Hi all, > > I'd like to start the discussion of the "Strict operators directive" RFC > version 1.5. This RFC proposes a new directive strict_operators, which > limits the type juggling done by operators to avoid unexpected results. > > https://wiki.php.net/rfc/strict_operators > > There are some significant changes from the previous version. > strict_operators no longer has cases where it changes the outcome of an > operation. To achieve this the following changes are made to the RFC > > * All comparison operators, besides `===` and `!==`, only accept `int` and > `float` operands. For any other type a `TypeError` is thrown. This includes > `==` and `!=`. > what about DateTime and other objects overwriting comparison operators? (GMP, ...) How would this proposal affect future proposals that expose comparisons to userland (see for example the operator overloading RFC). * The `switch` statement is not affected. > > For frequently asked questions please see > https://wiki.php.net/rfc/strict_operators/faq. > Honestly PHP comparisons are already complex enough, introducing a second set of rules that are just as complex seems like a risky proposal to me. > > [Arnold Daniels - Chat @ Spike]( > https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=l1bam) > [l1bam]
Re: [PHP-DEV] [RFC][DISCUSSION] Strict operators directive
Hey Arnold, Perhaps it makes sense for <=> to still operate with other types, as long as they are uniform? Specifically: * error: 1 <=> "1" * ok: "a" <=> "b" * ok: true <=> false Similar for sorting: I use <=> to differentiate multi-dimensional arrays: perhaps it should error if the array structure differs? The rest of the proposal makes a lot of sense to me. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Mon, Jul 6, 2020 at 5:27 PM Arnold Daniels wrote: > Hi all, > > I'd like to start the discussion of the "Strict operators directive" RFC > version 1.5. This RFC proposes a new directive strict_operators, which > limits the type juggling done by operators to avoid unexpected results. > > https://wiki.php.net/rfc/strict_operators > > There are some significant changes from the previous version. > strict_operators no longer has cases where it changes the outcome of an > operation. To achieve this the following changes are made to the RFC > > * All comparison operators, besides `===` and `!==`, only accept `int` and > `float` operands. For any other type a `TypeError` is thrown. This includes > `==` and `!=`. > * The `switch` statement is not affected. > > For frequently asked questions please see > https://wiki.php.net/rfc/strict_operators/faq. > > [Arnold Daniels - Chat @ Spike]( > https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=l1bam) > [l1bam]
[PHP-DEV] [RFC][DISCUSSION] Strict operators directive
Hi all, I'd like to start the discussion of the "Strict operators directive" RFC version 1.5. This RFC proposes a new directive strict_operators, which limits the type juggling done by operators to avoid unexpected results. https://wiki.php.net/rfc/strict_operators There are some significant changes from the previous version. strict_operators no longer has cases where it changes the outcome of an operation. To achieve this the following changes are made to the RFC * All comparison operators, besides `===` and `!==`, only accept `int` and `float` operands. For any other type a `TypeError` is thrown. This includes `==` and `!=`. * The `switch` statement is not affected. For frequently asked questions please see https://wiki.php.net/rfc/strict_operators/faq. [Arnold Daniels - Chat @ Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=l1bam) [l1bam]
[PHP-DEV] Re: [RFC] Named arguments
On Fri, Jul 3, 2020 at 4:35 PM Nikita Popov wrote:
> On Mon, Jun 29, 2020 at 5:13 PM Nikita Popov wrote:
>
>> On Tue, Jun 23, 2020 at 12:10 PM Nikita Popov
>> wrote:
>>
>>> On Tue, May 5, 2020 at 3:51 PM Nikita Popov
>>> wrote:
>>>
Hi internals,
I've recently started a thread on resurrecting the named arguments
proposal (https://externals.io/message/109549), as this has come up
tangentially in some recent discussions around attributes and around object
ergonomics.
I've now updated the old proposal on this topic, and moved it back
under discussion: https://wiki.php.net/rfc/named_params
Relative to the last time I've proposed this around PHP 5.6 times, I
think we're technically in a much better spot now when it comes to the
support for internal functions, thanks to the stubs work.
I think the recent acceptance of the attributes proposal also makes
this a good time to bring it up again, as phpdoc annotations have
historically had support for named arguments, and this will make migration
to the language-provided attributes smoother.
Regards,
Nikita
>>>
>>> As we're moving in on feature freeze, I plan to move this proposal
>>> forward soonishly.
>>>
>>> I have update the RFC to drop the syntax as an open question (I haven't
>>> seen much opposition to the use of ":"), and to describe the possible
>>> alternative LSP behavior at
>>> https://wiki.php.net/rfc/named_params#parameter_name_changes_during_inheritance
>>> .
>>>
>>> While writing this down and implementing it, I found that this has more
>>> odd edge-cases than anticipated. Overall, I'm not sold that this approach
>>> is worth it. It sounds nice on paper, but I strongly suspect that it solves
>>> a problem that does not existing in practice, and will force us to keep
>>> this patch-over mechanism indefinitely, while the real solution would have
>>> been to fix the limited amount of code that is in the intersection of
>>> "renames parameters" and "is actually invoked with named arguments".
>>>
>>
>> Just as another reminder: I plan to put this to voting by the end of the
>> week.
>>
>> I've also updated the RFC to make the LSP behavior a secondary vote. I'm
>> not convinced this is a good idea myself, but some others seemed to prefer
>> this approach.
>>
>
> I've made two additional changes to the proposal:
>
> 1. Explicitly mentioned attribute support in
> https://wiki.php.net/rfc/named_params#attributes1, and added it to the
> implementation (oops). ReflectionAttribute::getArguments() will also return
> named arguments to the attribute, and ReflectionAttribute::newInstance()
> will behave in the intuitive manner.
>
> 2. Added some information on internal APIs in
> https://wiki.php.net/rfc/named_params#internal_apis. The tl;dr is that
> named params are pretty much completely transparent for normal extensions,
> but there are some additional APIs if for example you want to perform a
> named param call from an extension.
>
>
> In relation to this, I'm also considering to change the semantics of
> call_user_func_array() to treat array elements with string keys as named
> parameters, rather than simply ignoring keys. The motivation here is not so
> much call_user_func_array() in particular, but various other APIs that do
> the same thing, such as ReflectionMethod::invokeArgs(), which should all
> behave consistently.
>
> Relatedly, I'm wondering if something like this should be allowed:
>
> call_user_func('strlen', str: 'foo');
>
> I'm leaning towards "yes", in which case call_user_func_array() should be
> also be treated consistently.
>
Okay, I think I've now done the last set of updates to this RFC:
* call_user_func(), call_user_func_array(),
ReflectionClass::newInstance(), ..., now support named parameters.
* I've moved the alternative LSP behavior into the alternatives section
and don't plan to pursue it in this RFC. After thinking it over, I think
this is a nice migration hack, but not something that should be part of the
language long term.
Regards,
Nikita
[PHP-DEV] Proposal: A way for classes to define a response to any primitive type cast
Apologies, first time, still learning and have no historical context - timing
is what it is.
Proposal type: Concept
Implementer: Unknown, fallback to me after slow learning
Presumed simple implementation as the pattern should already be in place:
Cast of (string) -> __toString() - already implemented
Cast of (bool) -> __toBool()
Cast of (int) -> __toInt()
Cast of (object) -> __toObject()
…and so on.
Alternative implementation using an interface:
\CastableTo{type}
Extreme implementation:
Make both of the previous available.
Known unknowns:
- Level of interest in something like this in the PHP community outside of one
upvote on a Stackoverflow question I submitted:
https://stackoverflow.com/questions/62747837/php-7-tostring-or-other-interface-for-boolean-values
- Whether this conversation or proposal has already occurred.
- The historical conversation leading to the creation of the __toString()
method (and stopping there).
- The current conversation around using magic methods in general and
specifically when defining a cast response.
- Enough details on PHP internal development to implement myself (this is the
first time in 20 years I felt I couldn’t comfortably accomplish what I wanted
to, thanks for that).
- What potential collisions could occur if someone (me) wanted to implement all
possibilities in a single class.
- Right now __toBool() would be of the most personal benefit - if proposal is
converted to an RFC, would it be better (faster/smoother) to do one RFC for all
the cast possibilities - or to have an RFC for each cast separately?
Thank you for the consideration, information, and feedback.
Cheers,
Josh
ps. Also, apologies again for walking into a new space on a mission, not my
normal approach.
pps. The primary project inspiring the proposal:
https://github.com/8fold/php-shoop
