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(a)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(a)redhat.com> wrote:
> Thanks for the update, Brain.
>
> On Tue, Aug 16, 2022 at 12:27 AM Brian Stansberry <
> brian.stansberry(a)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
>>
>