On Fri, Jul 31, 2015 at 9:56 PM, Stanislav Malyshev <smalys...@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 debugging > > 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-in-a-database ). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
