Thanks, Jim and Richard.

Without objection I'd like to merge that PR and do a release so there's enough time to get CI / TCK results before we tag 26.1.2 next Wed.

On Thu, Aug 18, 2022 at 3:37 PM Richard Opalka <ropalka@redhat.com> wrote:
Hello Brian,

   I added a comment into WFLY-16771.

Rio

On Tue, Aug 16, 2022 at 10:24 AM Jim Ma <ema@redhat.com> wrote:
Thanks for the update, Brain. 

On Tue, Aug 16, 2022 at 12:27 AM Brian Stansberry <brian.stansberry@redhat.com> wrote:
Hi Richard, Jim and Scott, everyone,

FYI re https://github.com/jboss/xalan-j/pull/7, which is a fix for https://issues.redhat.com/browse/WFLY-16771 to avoid a problem in the org.apache.bcel classes that xalan-jar 2.7.1.jbossorg-5 shades in. There was a CVE (CVE-2022-34169) filed against the JDK involving its fork of those BCEL classes, but there is no fix in BCEL itself.

The change there removes BCEL from the xalan-j jar and changes the default TransformerFactory to xalan's impl class that does not use BCEL. This is a fairly significant change, particularly for 26.1.2, so I wanted to point it out here.

Note that for many years now the fork of xalan-j that Red Hat produces for inclusion in Red Hat JBoss EAP does not include BCEL and uses the TransformerFactory impl class that my PR moves to. So that kind of xalan setup has a lot of bake running workloads based on the WF technology stack.

Perhaps we could add an optional module.xml dep on a non-existent xalan.org.apache.bcel module to our org.apache.xalan module, so on the off chance anyone is affected by this they could create said module to make bcel visible to xalan-j.

Best regards,
Brian


--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His