I'm not much focused on 8.x at the moment. Shipping with a Jackson RC is fine in my opinion. And yes it's ridiculous to have 2 JSON-B/P implementations. The thing is that OpenAPI has a hard dependency on Jackson as opposed to be using standard APIs where you can use any implementation.
-- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Mon, Oct 10, 2022 at 9:11 AM Wiesner, Martin < martin.wies...@hs-heilbronn.de> wrote: > Hi all, > > I agree with Alex’s comments on Richard’s proposed options for the next > TomEE 8.x release. > We should move on and ship 8.0.13 soon. > > Best > Martin > — > https://twitter.com/mawiesne > > > Am 09.10.2022 um 13:11 schrieb Alex The Rocker <alex.m3...@gmail.com>: > > Hello, > > Regarding # (1): CVE-2022-42003 (jackson-databind), given that the > only reason for having Jackson in TomEE is because of embedded TomEE; > so the discussion here > https://lists.apache.org/thread/ttmdc4l9z9oz9lqw3cd22sjdz451dh25 to > replace Jackson by the Apache Johnzon (which is already part of TomEE) > should really move on. > Not only it is ridiculous to have two JSON processing stacks > cohexisting in TomEE, but also, looking at > https://mvnrepository.com/artifact/org.apache.johnzon/johnzon-core, > there was no CVE on Johnzon for the part 5 years ; versus a huge > number of CVE on Jackson for the same period: > > https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind > > Regarding "# (2): CVE-2022-41853 (hsqldb)", I vote for solution (b) > Add the workaround (via java args) to our startup scripts and go > for the release , because it helps avoiding further delay at 8.0.3 > releasing, and it's better than (c) because TomEE will be "secure by > default") > > That were my 2 cents, > Alex > > Le dim. 9 oct. 2022 à 09:44, Richard Zowalla <r...@apache.org> a écrit : > > > Hi all, > > I think, that we are soon in a good state to do a 8.0.13. > > However, there are some open points for which I want to get the > community's opinion. > > # (1): CVE-2022-42003 (jackson-databind) > > Were is one CVE related to jackson-databind: > > https://nvd.nist.gov/vuln/detail/CVE-2022-42003 (before 2.14.0-rc1) > > Users are only affected, if 'UNWRAP_SINGLE_VALUE_ARRAYS' is set to > enabled [1]. AFAIK, we do not enable that feature by default. > > There is an ongoing discussion about 2.14.0 final on their list but it > seems that it will be late October / mid November until they will > release that artifact. > > Question(s) to discuss is: > > (a) Do we want to ship a release with a RC version? > (b) Do we want to wait for 2.14.0.Final? > (c) Do we want to ship with 2.13.4 instead + adding a related section > to our release notes? > > # (2): CVE-2022-41853 (hsqldb) > > In addition, were is CVE-2022-41853, which affects HSQLDB < 2.7.1. > 2.7.1 isn't available yet [2]. A workaround is to set a related sytsem > property to mitigate the behaviour. > > Question(s) to discuss is: > > (a) Do we want to wait for a 2.7.1 release before doing 8.0.13 (AFAIK, > no ETA yet) > (b) Add the workaround (via java args) to our startup scripts and go > for the release > (c) Ship with 2.7.0 + adding a related section to our release notes? > > Keep in mind: If we do not update to the "official" fix version (even > if we add related infos on our release note or mitigate via the > official workaround), automated security scanners will complain about > it and ops / security people will wonder about it. > > Happy to receive feedback on these questions, so we can continue. > > Gruß > Richard > > > > > [1] > > https://github.com/FasterXML/jackson/discussions/126#discussioncomment-3815395 > [2] https://github.com/advisories/GHSA-77xx-rxvh-q682 > > > > > >
