Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87460
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55BBD2EE.2070008@gmail.com>
References: <550FA2ED.6080000@gmail.com>
	<CADR=R-gtCy7Vi7Y15jx+SYWX3aEB6TN3WGJPAqqQ4tO__SWqQw@mail.gmail.com>
	<CAF+90c8c8_Vth3vVaYF1N1u68JANTbGDq-QUTvG44X+Wr+oe0A@mail.gmail.com>
	<55B7B08E.7070700@gmail.com>
	<CAH-PCH7Yw8KWZa5oLguUjD2-3DrSsH0Kb7cO9yLKYy4UNETWCQ@mail.gmail.com>
	<55BBD2EE.2070008@gmail.com>
Date: Fri, 31 Jul 2015 23:23:03 +0200
Message-ID: <CAH-PCH4AgZdffaoCdBwdmE2ppQb7yMqt=M_J3WDR9Az9PvCDkQ@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3416cdb5355051c326c81
Subject: Re: [PHP-DEV] Re: Serializing exceptions
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c3416cdb5355051c326c81
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 31, 2015 at 9:56 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > Personally I feel the restoring them impossible argument weak, consider
> > that we allow stuff like serializing resources without even a notice.
>
> Not sure what you mean by that. If you try to serialize resource, you
> just get an integer. Not ideal, as a remanant of the times in PHP where
> the approach was "if it doesn't make sense, do whatever and hope the
> user is ok with that", but certainly it's not "serializing resources".
>

your argument was that we shouldn't allow serialization of such items where
after the unserliazion you won't get the same thing back.
this is where my point about we allow serializing resources just fine was
aimed at.


> It's "ignoring resources when serializing and producing integers
> instead". Replacing Exceptions with integers probably won't work that
> well :)
>

nobody suggested replacing Exceptions with integers, but serializing
Closure to "Closure #1" or similar (albeit we could even do a better job,
similarly how java8 supports lambda serialization).


>
> > Based on my own experiences where I had to fix multiple apps when we
> > introduced the unserializable Closure (mostly error logger and debuggin=
g
> > tools) which got passed as argument in the backtrace I would prefer if
> > we could remove that restriction.
>
> I don't see how we can really remove the underlying problem - Exceptions
> contain backtraces, which means serializing them tries to serialize a
> ton of stuff that may be not only not serializable but outright
> dangerous to carry around - such as keys, passwords, etc.


var_export() shares the same problem, should we then also try to remove
__toString() from closures?
or try for looking for passwords or credit card data in the variable?
I think that your argument is really streched. I'm not saying that we
should give more rope for the developers to hang themselves but the current
situations sucks (you can serialize basically anything but Closure) and I
think that your suggested way of solving the problem would create a medium
sized BC break for little gain as it would only fix a specific scenario
(people like in your SO link in the opening post would still try to
debug_backtrace() from their logger/debugger which would trigger the same
problem that the Closure arg can't be serialized).


> Given how many
> problems we have had with serialization of complex objects lately, and
> given that I still see absolutely no practical use of actually
> serializing exceptions I would rather remove it and reduce the
> vulnerable surface than keep dealing with dozens of issues that continue
> to pop up from that.
>

that's true, but you would only remove a single attack vector via removing
an otherwise useful feature
those issues would be still present, still reported, we should still fix
then, even if you can't trigger them via an exception logger but a session
unserialized.


> BTW what you mean by "unserializable Closure"? As far as I know you can
> not serialize Closure.
>

I mean exactly that and btw. that was the original problem in the
Stackoverflow post you cited in your opening post (
http://stackoverflow.com/questions/9747813/storing-a-php-exception-object-i=
n-a-database
).

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a11c3416cdb5355051c326c81--