jamesnetherton opened a new pull request, #9116:
URL: https://github.com/apache/camel-quarkus/pull/9116

   Camel restricts access to external DTDs and stylesheets on the 
TransformerFactory it creates. The xslt extension supplies its own factory, so 
those restrictions were not applied to the transformations it performs. The 
factory is also registered as the JAXP default, so this covers any code 
obtaining one through TransformerFactory.newInstance(), including applications 
using camel-quarkus-tika and camel-quarkus-xmlsecurity, which depend on the 
same support extension without using XSLT themselves.
   
   XalanTransformerFactory now applies the restrictions itself:
   
   * Documents being transformed are parsed with an XMLReader that does not 
resolve external general entities, matching what Camel's XmlConverter does for 
the bodies camel-xslt converts to a SAXSource itself. A SAXSource carrying a 
caller configured XMLReader is used as it is, and DOMSource and StAXSource are 
already parsed.
   * Resources fetched at transform time by document() are denied unless the 
application's own URIResolver resolves them. Xalan does not propagate the 
factory resolver onto everything it hands out, so it is installed on each entry 
point; an application setting its own resolver, which camel-xslt does on every 
exchange, keeps overriding it as before.
   
   xsl:import and xsl:include are unchanged. Xalan dereferences those hrefs 
itself while compiling, so they cannot be restricted here, which matches what 
plain Camel does on the component path. A test pins that behaviour so a Xalan 
upgrade changing it does not go unnoticed.
   
   CamelXsltRecorder applies quarkus.camel.xslt.features to every template 
instead of only to those compiled to a translet at build time, where it 
previously had no effect on templates loaded at runtime, and warns once when 
secure processing is disabled.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to