>
> 1) Is notsoserial a "great solution" or a "useful solution" in mitigating
> the problem of promiscuous deserialization?
>
Useful? Certainly
2) Is it a "better" solution than IO-487?
>
Not sure - but does that really matter? It has a broader scope.
3) Is it in the interest of Commons and
Hi Eirik,
On Fri, Nov 20, 2015 at 7:52 AM, Eirik Bjørsnøs wrote:
> ...Do we need a declare a "winner" between notsoserial and IO-487..
I don't think so, definitely not - both are useful tools for different
use cases.
> ...My take is that if a donation to Apache Commons can
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
On 11/20/15 7:33 AM, Bertrand Delacretaz wrote:
> Hi Eirik,
>
> On Fri, Nov 20, 2015 at 7:52 AM, Eirik Bjørsnøs wrote:
>> ...Do we need a declare a "winner" between notsoserial and IO-487..
> I don't think so, definitely not - both are useful tools for different
> use cases.
>
Hi,
I'm not a committer but interested and looking forward to work on/with both
solutions.
-- Uwe
On November 20, 2015 6:50:53 PM Phil Steitz wrote:
On 11/20/15 7:33 AM, Bertrand Delacretaz wrote:
Hi Eirik,
On Fri, Nov 20, 2015 at 7:52 AM, Eirik Bjørsnøs
On Fri, Nov 20, 2015 at 12:50 PM, Phil Steitz wrote:
> ...So the real question is is anyone interested in working on
> this code?...
Good question indeed - I'll very probably use it so yes I would
contribute to its maintenance.
-Bertrand
>
> > ...it feels a bit like putting a thumb into a hole to stop the water.
> > People need to re-think their use of reflection and serialization - not
> > cover up bad engineering practices...
>
> Absolutely - but depending on people's use of serialization it will
> take a while until all holes
On Thu, Nov 19, 2015 at 9:40 AM, Jochen Wiedmann
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
On Thu, Nov 19, 2015 at 5:39 AM, Torsten Curdt wrote:
> ...it's just that the term "great solution"
> struck me as inappropriate
Well I did say "great solution...for cases when one cannot modify
their source code..." ;-)
-Bertrand
On Wed, Nov 18, 2015 at 10:58 PM, Bertrand Delacretaz
wrote:
> I tested his agent in a variety of scenarios and it looks to me like a
> great solution for the COLLECTIONS-580 deserialization issue, for
> cases when one cannot modify their source code to use something like
Hi Commons PMC,
I'd like to introduce Eirik Bjørsnøs to this list (CCed) as the author
of the https://github.com/kantega/notsoserial agent.
I tested his agent in a variety of scenarios and it looks to me like a
great solution for the COLLECTIONS-580 deserialization issue, for
cases when one
Using the agent in (and only in) whitelist mode is a pretty strong and
quick security measure.
Calling this a "great solution" still goes against my inner developer soul
though.
It's pragmatic and a good tool - that I am on board with. (Cool stuff,
Eirik)
Yet it feels a bit like putting a thumb
On Wed, Nov 18, 2015 at 7:16 PM, Torsten Curdt wrote:
> ...it feels a bit like putting a thumb into a hole to stop the water.
> People need to re-think their use of reflection and serialization - not
> cover up bad engineering practices...
Absolutely - but depending on people's
Le 19/11/2015 01:24, Bertrand Delacretaz a écrit :
On Wed, Nov 18, 2015 at 7:16 PM, Torsten Curdt wrote:
...it feels a bit like putting a thumb into a hole to stop the water.
People need to re-think their use of reflection and serialization - not
cover up bad engineering
14 matches
Mail list logo