TomEE 8.0.12 is already affected by these 2 CVE, right? i am unsure in terms of corporate image. no-shipping and waiting seems a bit hard on clients who would need to have tech-watch and/or security teams to update the jars by themselves in production.
it would be great to provide counter mesures when there are, maybe ship asap so clients have them: jackson (a) shipping even RC (more stable than milestone) hsqldb (b) the script flags, but with work to do next time to remove them and update deps. + release note. that's more job on TomEE contributors side but clients may be happy about transparency and counter mesures provided? even more if 8.0.12 is already affected. ops/security people always read the release notes, right? another point of view is we are not responsible for other software CVEs and security teams should always be prepared to update things like the os and stuff including libraries. two shippings in 2 months seems fair, but i'm not the one doing the releases. :-) have a nice Sunday! -- Swell On Sun, 9 Oct 2022 at 09:44, Richard Zowalla <r...@apache.org> wrote: > 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 > > > > >
