Hi!
> Thanks for responding to this issue.
>
> Will calling getMetaData still parse andÂ
> execute malicious code?
If it's contained in phar and serialized data and the surrounding code
(I understand that most techniques mentioned in the article rely on
certain vulnerable code being present) the
Hi,
Thanks for responding to this issue.
Will calling getMetaData still parse and
execute malicious code?
;__
Raymond
On Sun, 14 Apr 2019, 4:47 PM Stanislav Malyshev,
wrote:
> Hi!
>
> > I came across this article which highlights a few issues with PHP
> > deserialization techniques:
> >
>
Hi!
> I came across this article which highlights a few issues with PHP
> deserialization techniques:
>
> https://portswigger.net/daily-swig/phar-out-php-deserialization-techniques-offer-rich-pickings-for-security-researchers
PHP serialization is not meant to be used with external or
user-modify
On Mon, Apr 8, 2019 at 4:06 PM Nikita Popov wrote:
> On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
>
>> Hi internals,
>>
>> Motivated by the recent list comprehensions RFC, I think it's time we
>> took another look at short closures:
>>
>> https://wiki.php.net/rfc/arrow_functions_v2
>>
>>
Hello,
people familiar with the PHP *nix build system today can be probably
counted on the fingers of two hands, so I'm hoping to get some answer
also here.
Does anyone maybe still have any insights on which Make version does
PHP require or silently specify as a minimum? GNU make? POSIX make?
May
Hello Team,
I came across this article which highlights a few issues with PHP
deserialization techniques:
https://portswigger.net/daily-swig/phar-out-php-deserialization-techniques-offer-rich-pickings-for-security-researchers
A thought -
In the event that explicit casting specifically does get tightened up,
what will become the suggested method for making a best-effort
conversion to an integer?
Personally I'm in favour of explicit casts being a bit more forgiving,
but in the event they're not, what will replace i
