Created attachment 68349 [details]
here's a configure test to catch this miserable java-world issue

As an aside saxon-he doesn't come with a build.xml which makes a
META-INF/services/javax.xml.transform.TransformerFactory entry of
net.sf.saxon.TransformerFactoryImpl which is another problem that causes that
saxon to be ignored the a jaxp provider when just bunged into the classpath

*** Issue 100329 has been marked as a duplicate of this issue. ***

*** Issue 100328 has been marked as a duplicate of this issue. ***

*** Issue 100327 has been marked as a duplicate of this issue. ***

*** Issue 100325 has been marked as a duplicate of this issue. ***

*** Issue 100326 has been marked as a duplicate of this issue. ***

*** Issue 100324 has been marked as a duplicate of this issue. ***

I assume the original reason to use saxon at all in the first place was to
support xslt2, and it seems the only game in town to do this.

Added a configure test to detect useless saxon versions. 

Reassigning for qa, to make sure this works on debian (or correctly fails if
that saxon doesn't cut the mustard)

with the known not working saxon.jar:

checking which saxon to use... external
checking for /usr/share/java/saxon.jar... yes
checking if saxon works... no
configure: error: Non-functional saxon jar, e.g. crippled saxon-he instead of saxonb

-> OK

with saxonb.jar:

checking which saxon to use... external
checking for /usr/share/java/saxonb.jar... yes
checking if saxon works... no
configure: error: Non-functional saxon jar, e.g. crippled saxon-he instead of saxonb

I don't think I have the he as at least

   creating: META-INF/service/
  inflating: META-INF/service/javax.xml.transform.TransformerFactory

is present, though which I guess is what you mean by your comment..

But I stumbled over this in README.Debian:

--- snip ---
Calls on external Java functions disabled by default
----------------------------------------------------

By default, SaxonB enables calls on external Java functions to be
embedded in stylesheets or queries. Such calls can invoke arbitrary
Java methods and are thus a security risk when executing untrusted
XSLT stylesheets of XQuery queries.  For this reason, SaxonB in Debian
comes with calls on external Java functions disabled by default.
[...]
If you are using SaxonB from its Java API you should set the Attribute
"FeatureKeys.ALLOW_EXTERNAL_FUNCTIONS" to "true". See the API
reference in the libsaxonb-java-doc package for more information.
--- snip ---

and indeed, when disabling the patch it works.

I think this bug can be set to VERIFIED, the check rejects broken saxons at
least for me...

note to myself: now to look where to best add that Attribute setting...

think I got it... This patch (in addition to saxon.test.patch) makes configure
pass (and probably also makes it work)

Created attachment 68423 [details]
proposed patch

Rene brought this bug to my attention, doesn't the fact that this works with the
OOo version of saxonb but not the Debian version mean that the one in OOo has a
security hole?

yeah, thinking of it a bit more I don't feel good with this either... Sounds
like the hsqldb issue not long ago....

Ccing mt and ause (who added it apparently)

regardless of that - hmm. I still get a "Error saving the document oo: Write
Errir, The file could no be written." when trying to save as uot

Saxon was added by myself some while ago, therefore instead of Ause who just
assisted and was the commited, I can see as the responsible person for Saxon.

Thought about an update of Saxon anyway due to 97173, therefore I will have a
closer look in this after the ISO SC34 meeting next week (plus vacation).

Best regards,
Svante

close issue.