> TomEE 8.0.12 is already affected by these 2 CVE, right? Yes (+ some others as discussed in the 'Cut a 8.0.13' thread).
Gruß Richard Am Sonntag, dem 09.10.2022 um 10:59 +0200 schrieb Swell: > 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 > > > > > > > > > >
smime.p7s
Description: S/MIME cryptographic signature
