You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Enrico Olivelli <eo...@gmail.com> on 2020/02/23 09:09:14 UTC
Getting rid of Jackson Databind ?
Hi,
we are using a library, Jackson Databind, to serialize JSON objects on
the HTTP Admin Endpoint.
Unfortunately that library is very ofter subject to CVEs due to the
intrinsic nature of the library, the fact that is really very common
and in particular to the fact that it has many deserialization
"gadgets" (that we are not using).
Usually we are never affected by those CVEs because we are using only
Jackson core features and we are using it only in order to serialize
data (and only very simple beans).
Some more context here:
https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062
We want OWASP dependency checker to be always happy with our releases.
I think this is very good.
But we are spending lot of time, especially in blocking releases due
to these fact.
I am now proposing to drop this dependency and use some other simpler
JSON encoding library.
Thoughts ?
Enrico
Re: Getting rid of Jackson Databind ?
Posted by Tamas Penzes <ta...@cloudera.com.INVALID>.
Here they say 2.10 is already okay and should not contain that many CVEs as
2.9 https://medium.com/@cowtowncoder/jackson-2-10-features-cd880674d8a2
What do you think?
On Sun, Feb 23, 2020 at 9:49 PM Enrico Olivelli <eo...@gmail.com> wrote:
> Il Dom 23 Feb 2020, 17:12 Patrick Hunt <ph...@apache.org> ha scritto:
>
> > On Sun, Feb 23, 2020 at 1:09 AM Enrico Olivelli <eo...@gmail.com>
> > wrote:
> >
> > > Hi,
> > > we are using a library, Jackson Databind, to serialize JSON objects on
> > > the HTTP Admin Endpoint.
> > >
> > > Unfortunately that library is very ofter subject to CVEs due to the
> > > intrinsic nature of the library, the fact that is really very common
> > > and in particular to the fact that it has many deserialization
> > > "gadgets" (that we are not using).
> > >
> > > Usually we are never affected by those CVEs because we are using only
> > > Jackson core features and we are using it only in order to serialize
> > > data (and only very simple beans).
> > >
> > > Some more context here:
> > >
> > >
> > >
> >
> https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062
> > >
> > >
> > > We want OWASP dependency checker to be always happy with our releases.
> > > I think this is very good.
> > > But we are spending lot of time, especially in blocking releases due
> > > to these fact.
> > >
> > > I am now proposing to drop this dependency and use some other simpler
> > > JSON encoding library.
> > >
> > > Thoughts ?
> > >
> > >
> > +1 - makes sense to me. Can we find something with a permissive license,
> > that's minimal, has a history of success/support and will minimize
> impact?
> >
>
> What about this minimal version of Jackson?
>
> https://github.com/FasterXML/jackson-jr
>
>
> Enrico
>
> >
> > Thanks,
> >
> > Patrick
> >
> >
> > > Enrico
> > >
> >
Re: Getting rid of Jackson Databind ?
Posted by Enrico Olivelli <eo...@gmail.com>.
Il Dom 23 Feb 2020, 17:12 Patrick Hunt <ph...@apache.org> ha scritto:
> On Sun, Feb 23, 2020 at 1:09 AM Enrico Olivelli <eo...@gmail.com>
> wrote:
>
> > Hi,
> > we are using a library, Jackson Databind, to serialize JSON objects on
> > the HTTP Admin Endpoint.
> >
> > Unfortunately that library is very ofter subject to CVEs due to the
> > intrinsic nature of the library, the fact that is really very common
> > and in particular to the fact that it has many deserialization
> > "gadgets" (that we are not using).
> >
> > Usually we are never affected by those CVEs because we are using only
> > Jackson core features and we are using it only in order to serialize
> > data (and only very simple beans).
> >
> > Some more context here:
> >
> >
> >
> https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062
> >
> >
> > We want OWASP dependency checker to be always happy with our releases.
> > I think this is very good.
> > But we are spending lot of time, especially in blocking releases due
> > to these fact.
> >
> > I am now proposing to drop this dependency and use some other simpler
> > JSON encoding library.
> >
> > Thoughts ?
> >
> >
> +1 - makes sense to me. Can we find something with a permissive license,
> that's minimal, has a history of success/support and will minimize impact?
>
What about this minimal version of Jackson?
https://github.com/FasterXML/jackson-jr
Enrico
>
> Thanks,
>
> Patrick
>
>
> > Enrico
> >
>
Re: Getting rid of Jackson Databind ?
Posted by Patrick Hunt <ph...@apache.org>.
On Sun, Feb 23, 2020 at 1:09 AM Enrico Olivelli <eo...@gmail.com> wrote:
> Hi,
> we are using a library, Jackson Databind, to serialize JSON objects on
> the HTTP Admin Endpoint.
>
> Unfortunately that library is very ofter subject to CVEs due to the
> intrinsic nature of the library, the fact that is really very common
> and in particular to the fact that it has many deserialization
> "gadgets" (that we are not using).
>
> Usually we are never affected by those CVEs because we are using only
> Jackson core features and we are using it only in order to serialize
> data (and only very simple beans).
>
> Some more context here:
>
>
> https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062
>
>
> We want OWASP dependency checker to be always happy with our releases.
> I think this is very good.
> But we are spending lot of time, especially in blocking releases due
> to these fact.
>
> I am now proposing to drop this dependency and use some other simpler
> JSON encoding library.
>
> Thoughts ?
>
>
+1 - makes sense to me. Can we find something with a permissive license,
that's minimal, has a history of success/support and will minimize impact?
Thanks,
Patrick
> Enrico
>