Re: Remove Xalan and here() function support

[Sean Mullan <se...@oracle.com>]

Colm,

Should SANTUARIO-583 [1] also be closed or marked as a duplicate of 
SANTUARIO-593 [2]?

--Sean

[1] https://issues.apache.org/jira/browse/SANTUARIO-583
[2] https://issues.apache.org/jira/browse/SANTUARIO-593

On 8/30/22 8:03 AM, Sean Mullan wrote:
> I support this proposal. I think the "here" function was never specified
> correctly anyway as I have been told a while ago by an XPath expert that
> it should have been defined in a namespace in order to be properly
> processed as an XPath extension.
> 
> --Sean
> 
> On 8/30/22 4:04 AM, Colm O hEigeartaigh wrote:
>> Hi all,
>>
>> I'd like to propose removing Xalan as an (optional) dependency and
>> also support as a result for the here() function defined in the spec:
>> https://www.w3.org/TR/xmldsig-core1/#function-here
>>
>> To re-cap, currently for XPath we use the default Java implementation.
>> Xalan is an optional dependency, meaning that someone has the ability
>> to add Xalan to the classpath, in which case Xalan will be used
>> instead. For Xalan, we do some hacking to support the here() function:
>>
>> https://github.com/apache/santuario-xml-security-java/blob/12466b78dcac65e6442d50571c1e6d5dd7748b84/src/main/java/org/apache/xml/security/utils/XalanXPathAPI.java#L162
>>
>> This is a little-used part of the spec, that causes a few tests to
>> fail if we remove it. From previous conversations it doesn't seem
>> easily possible to support this function using the JDK implementation.
>>
>> A recent serious security issue was published for Xalan which makes it
>> clear the project is being retired -
>> https://nvd.nist.gov/vuln/detail/CVE-2022-34169. I think it's time
>> that we removed it, even though it's obviously not ideal that we are
>> then not fully implementing the spec. We can make it pluggable so that
>> someone can add the code back in if they want to use it.
>>
>> Thoughts?
>>
>> Colm.

Re: Remove Xalan and here() function support

[Colm O hEigeartaigh <co...@apache.org>]

Yes thanks, I marked it as a duplicate.

Colm.

On Thu, Sep 1, 2022 at 12:14 PM Sean Mullan <se...@oracle.com> wrote:
>
> Colm,
>
> Should SANTUARIO-583 [1] also be closed or marked as a duplicate of
> SANTUARIO-593 [2]?
>
> --Sean
>
> [1] https://issues.apache.org/jira/browse/SANTUARIO-583
> [2] https://issues.apache.org/jira/browse/SANTUARIO-593
>
> On 8/30/22 8:03 AM, Sean Mullan wrote:
> > I support this proposal. I think the "here" function was never specified
> > correctly anyway as I have been told a while ago by an XPath expert that
> > it should have been defined in a namespace in order to be properly
> > processed as an XPath extension.
> >
> > --Sean
> >
> > On 8/30/22 4:04 AM, Colm O hEigeartaigh wrote:
> >> Hi all,
> >>
> >> I'd like to propose removing Xalan as an (optional) dependency and
> >> also support as a result for the here() function defined in the spec:
> >> https://www.w3.org/TR/xmldsig-core1/#function-here
> >>
> >> To re-cap, currently for XPath we use the default Java implementation.
> >> Xalan is an optional dependency, meaning that someone has the ability
> >> to add Xalan to the classpath, in which case Xalan will be used
> >> instead. For Xalan, we do some hacking to support the here() function:
> >>
> >> https://github.com/apache/santuario-xml-security-java/blob/12466b78dcac65e6442d50571c1e6d5dd7748b84/src/main/java/org/apache/xml/security/utils/XalanXPathAPI.java#L162
> >>
> >> This is a little-used part of the spec, that causes a few tests to
> >> fail if we remove it. From previous conversations it doesn't seem
> >> easily possible to support this function using the JDK implementation.
> >>
> >> A recent serious security issue was published for Xalan which makes it
> >> clear the project is being retired -
> >> https://nvd.nist.gov/vuln/detail/CVE-2022-34169. I think it's time
> >> that we removed it, even though it's obviously not ideal that we are
> >> then not fully implementing the spec. We can make it pluggable so that
> >> someone can add the code back in if they want to use it.
> >>
> >> Thoughts?
> >>
> >> Colm.