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 > > > >
