> 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
I did flag this up on the ActiveMQ dev list again, so there is some discussion going on there. I did dig into what in ActiveMQ actually uses Jackson, and I'm not sure its very much: * DestinationsViewFilter * PartitionBrokerPlugin * ZooKeeperPartitionBroker * Partition & Target classes * PersistenceAdapterView I don't think the partition and zookeeper stuff is relevant in the context of what is embedded in TomEE, and the rest looks like a couple of things that are exposed as stats via JMX. One option (which I'll look at) might be to just "drop" Jackson from the build artifact and see what, if anything, actually breaks. In terms of the release, I'd be in favour of going ahead, and following up with 8.0.14 quickly if the updated dependencies are released. We tend to wait for dependencies which makes our release cadence slower. 1: (a) 2: (b) Thanks Jon On Sun, Oct 9, 2022 at 12:11 PM Alex The Rocker <alex.m3...@gmail.com> wrote: > 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 > > > > > > > > >
