Re: Remove Xalan and here() function support
Yes thanks, I marked it as a duplicate. Colm. On Thu, Sep 1, 2022 at 12:14 PM Sean Mullan 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.
Re: Remove Xalan and here() function support
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
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.
Remove Xalan and here() function support
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.
