On Saturday, November 21, 2015 at 3:36:02 PM UTC+1, Jens wrote:
>
> I think a flag to disable the enhanced classes feature isn't worth it.
> Apps that need that feature will stop working so they won't use that flag.
> Apps that do not use this feature are not vulnerable unless the attacker
>
> AIUI this actually has nothing to do with Apache Commons, but about any
> case of deserialization of untrusted data:
> https://www.owasp.org/index.php/Deserialization_of_untrusted_data
>
I think a flag to disable the enhanced classes feature isn't worth it. Apps
that need that feature will stop working so they won't use that flag. Apps
that do not use this feature are not vulnerable unless the attacker can
also control the content of the rpc policy file somehow.
I would output
Elemental2 will be just an auto-generated thin wrapper around the browser
APIs. Unlike Elemental1, it will not provide a cross platform JSON
implementation.
I don't think you need to report compatibility bugs for Elemental1 unless a
maintainer steps up and shows interest.
On Sat, Nov 21, 2015 at
There could be a separate Json library build with JsInterop. Some of the
decisions I made in the design of the original Elemental JSON were made
specifically because of DevMode support and GWT optimization internals.
Given the unboxing of Double and Boolean, and the elimination of DevMode,
the
What's the current thinking regarding JSON in Elemental 2? That part has
always been a bit different from the DOM libraries, and I know there was
talk a long time back about splitting it out. I've been using Elemental
JSON extensively in my projects just to have a JSON library that works in
Apparently, GWT-RPC is vulnerable if you use "enhanced"
classes:
https://groups.google.com/d/msg/google-web-toolkit/j36D9-11JF4/OZwNQgvSAgAJ
Should we add a flag to GWT 2.8 disabling the special treatment of
"enhanced classes" in GWT-RPC, generating serialization policies without
