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 <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 >> >> >> >>
smime.p7s
Description: S/MIME cryptographic signature
