Hi all, thanks for your opinions.
Regarding (1): Updated to the RC version. Regarding (2): Added the workaround for hsqldb 2.7.0 - we can remove it after 2.7.1 is available. I am currently working on cleaning up the CXF shading for 8.0.13. This will give us the fixes in those classes, which we didn't incorporated through simple POM version updates since May 2021. Goal is to make it easier to upgrade CXF, i.e. to check the diffs of the classes we did modify on purpose in order to get the TCK working. Currently, the full build for that branch looks good: https://ci-builds.apache.org/job/Tomee/job/TOMEE-4057/2/ (or: https://github.com/apache/tomee/pull/942) I will merge it soon and get some TCK results. If they aren close to the usual results for 8.x, I will proceed with the further steps in getting 8.0.13 out of the door. Gruß Richard Am Montag, dem 10.10.2022 um 10:21 +0200 schrieb Jean-Louis Monteiro: > 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 > > > > > > > > > > > >
