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.
