Hi Commons PMC, (Sorry for being a bit late to the table)
I see three questions being discussed here: 1) Is notsoserial a "great solution" or a "useful solution" in mitigating the problem of promiscuous deserialization? 2) Is it a "better" solution than IO-487? 3) Is it in the interest of Commons and the community at large to accept a donation of this code and include it under its umbrella? The two first questions are interesting in themselves, but do we really need to reach any consensus on them? Is there requirement for solutions to be "great" to join Commons? Is "useful" sufficient? Do we need a declare a "winner" between notsoserial and IO-487? I see them as attacking the same problems from opposite sides where both angles are useful. Should you have a lock or an alarm in your house? The third question is not for be to decide. My take is that if a donation to Apache Commons can make people be more aware that this solution exists and that is a benefit for Commons and the community at large, then I'm not opposed to a donation. For my own personal interests, keeping it a Github project is probably simpler as Torsten mentions. However, I'm sure a lot of organisations would feel more comfortable using a solution vetted by a community such as Apache. Eirik. On Thu, Nov 19, 2015 at 3:47 PM, Bertrand Delacretaz <bdelacre...@apache.org > wrote: > On Thu, Nov 19, 2015 at 9:40 AM, Jochen Wiedmann > <jochen.wiedm...@gmail.com> wrote: > > ...but the solution from IO-487 looks to me to be much > > easier to use, in particular, because it shifts the burden on the > > container, or application vendor (where it belongs, IMO), and not on > > the end user running the container, or application.... > > Absolutely, I think both solutions are useful. > > IO-487 is the clean solution when you can modify your source code and > specify what you want to deserialize or not. > > Erik's notsoserial agent is a useful (and clever) fix for code that > you can't modify, or as a first step until you can modify and release > your code. > > -Bertrand >
