[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848901#comment-17848901
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2126717780
@slawekjaranowski Thanks for the great collaboration. We have achieved a
awesome result here.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would be affected by it would
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848750#comment-17848750
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski merged PR #242:
URL: https://github.com/apache/maven-invoker-plugin/pull/242
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would be affected by it would already have unparseable JUnit reports.
> * I _believe_ that Java's {{j.u.r.Pattern}} can trivially express the
>
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848535#comment-17848535
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2124388220
Let me try something locally:
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would be affected by it would already have unparseable JUnit reports.
> * I _believe_ that
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848507#comment-17848507
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2124199521
Hehe jenkins will fail because build use a previous version of invoker
and jenkins can not parse it ...
```
Failed to read test report file
/home/jenkins/jenkins-home/workspace/_box_maven-invoker-plugin_PR-242@2/linux-jdk17-m3.6.x_build/target/invoker-reports/TEST-MINVOKER-351.xml
org.dom4j.DocumentException: Error on line 341 of document : An invalid XML
character (Unicode: 0x7) was found in the element content of the document.
at org.dom4j.io.SAXReader.read(SAXReader.java:511)
at org.dom4j.io.SAXReader.read(SAXReader.java:392)
at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:186)
at hudson.tasks.junit.TestResult.parse(TestResult.java:390)
```
so will be fixed after release
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847704#comment-17847704
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2119309540
@michael-o, @elharo I try to fix plexus-xml
Here only add an IT which generate special chars in outputs ...
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847696#comment-17847696
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2119286251
> @elharo `BuildJob` serializer is generated by modello - `xpp3-writer` so
finally `MXSerializer` from plexus-utils is used
Right, I don't see a a way to get in between layers without monkey patching.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847695#comment-17847695
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2119283520
@elharo `BuildJob` serializer is generated by modello - `xpp3-writer` so
finally `MXSerializer` from plexus-utils is used
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847666#comment-17847666
]
ASF GitHub Bot commented on MINVOKER-351:
-
elharo commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2119205215
For working around the plexus bugs, is it possible to add an additional step
in between the build job and the serializer that escapes the message rather
than passing escaped values into the build job?
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
>
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847608#comment-17847608
]
ASF GitHub Bot commented on MINVOKER-351:
-
elharo commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2119020002
I guess it depends on what it means when a NUL character or other C0 control
appears here. It might be fine to drop them or replace each one with a space,
especially if you don't care about round triipping.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847607#comment-17847607
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2119019388
> > output:
> > ```
> > Exception in thread "main" java.lang.IllegalStateException: character 0
is not allowed in output
> > at
org.codehaus.plexus.util.xml.pull.MXSerializer.writeElementContent(MXSerializer.java:947)
> > at
org.codehaus.plexus.util.xml.pull.MXSerializer.text(MXSerializer.java:780)
> > at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.main(DefaultSiteRenderer.java:955)
> > ```
>
> . Character 0, i,e. ASCII NUL, and a few others are deeply problematic as
they can neither be included in XML documents nor escaped. If you're really
trying to wrap arbitrary binary data into XML then you have to Base 64 encode
it, though in this case we shouldn't be seeing those characters in the strings.
>
> Otherwise you need some sort of application specific convention for how
you'll encode the disallowed C0 controls. E.g. writing each one as an element
like ` or something like that. However you need to come up with
that yourself. The XML parser/serializer won't help you there. `
In our case the easiest way would be to drop them, no?
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847605#comment-17847605
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1605818675
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1640,7 +1642,7 @@ private void runBuild(
}
} catch (RunFailureException e) {
buildJob.setResult(e.getType());
-buildJob.setFailureMessage(e.getMessage());
+
buildJob.setFailureMessage(StringEscapeUtils.escapeXml10(e.getMessage()));
Review Comment:
> Assuming buildJob is just an object that contains strings and other
things, but has no particular XML internals (like 99.9% of classes that contain
strings) nothing inside it should be escaped.
>
> Ideally the XML writer should escape strings when it needs to. Or if the
XML writer is broken and won't do that, then the escaping should be done after
the string is extracted from the buildJob and before it's passed to the writer.
Escaping strings inside the buildJob breaks its semantics and tightly couples
all the classes together in one particularly brittle path.
Yes, the XML writer is broken and needs an issue.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847604#comment-17847604
]
ASF GitHub Bot commented on MINVOKER-351:
-
elharo commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2119018051
> output:
>
> ```
> Exception in thread "main" java.lang.IllegalStateException: character 0 is
not allowed in output
>at
org.codehaus.plexus.util.xml.pull.MXSerializer.writeElementContent(MXSerializer.java:947)
>at
org.codehaus.plexus.util.xml.pull.MXSerializer.text(MXSerializer.java:780)
>at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.main(DefaultSiteRenderer.java:955)
> ```
.
Character 0, i,e. ASCII NUL, and a few others are deeply problematic as they
can neither be included in XML documents nor escaped. If you're really trying
to wrap arbitrary binary data into XML then you have to Base 64 encode it,
though in this case we shouldn't be seeing those characters in the strings.
Otherwise you need some sort of application specific convention for how
you'll encode the disallowed C0 controls. E.g. writing each one as an element
like ` or something like that. However you need to come up with
that yourself. The XML parser/serializer won't help you there. `
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847594#comment-17847594
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118995261
And the value is indeed correct:
```java
Document doc2 =
DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(new
ByteArrayInputStream(w.toString().getBytes(StandardCharsets.UTF_8)));
NodeList childNodes = doc2.getDocumentElement().getChildNodes();
for (int i = 0; i < childNodes.getLength(); i++) {
System.out.println(childNodes.item(i).getTextContent());
}
```
output:
[Fatal Error] :3:19: Zeichenreferenz
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847593#comment-17847593
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118994193
I have now tested the IT with the patched Plexus XML. Output looks fine now:
```
[INFO] Running example.minvoker351.ExampleTest
- name: NULL
- name: START OF HEADING
- name: START OF TEXT
- name: END OF TEXT
- name: END OF TRANSMISSION
- name: ENQUIRY
- name: ACKNOWLEDGE
- name: BELL
- name: BACKSPACE
- name: CHARACTER TABULATION
- name: LINE FEED (LF)
- name: LINE TABULATION
- name: FORM FEED (FF)
- name: CARRIAGE RETURN (CR)
- name: SHIFT OUT
- name: SHIFT IN
- name: DATA LINK ESCAPE
- name: DEVICE CONTROL ONE
- name: DEVICE CONTROL TWO
- name: DEVICE CONTROL THREE
- name: DEVICE CONTROL FOUR
- name: NEGATIVE ACKNOWLEDGE
- name: SYNCHRONOUS IDLE
- name: END OF TRANSMISSION BLOCK
- name: CANCEL
- name: END OF MEDIUM
- name: SUBSTITUTE
- name: ESCAPE
- name: INFORMATION SEPARATOR FOUR
- name: INFORMATION SEPARATOR THREE
- name: INFORMATION SEPARATOR TWO
- name: INFORMATION SEPARATOR ONE
- name: SPACE
! - name: EXCLAMATION MARK
- name: QUOTATION MARK
# - name: NUMBER SIGN
$ - name: DOLLAR SIGN
% - name: PERCENT SIGN
- name: AMPERSAND
- name: APOSTROPHE
( - name: LEFT PARENTHESIS
) - name: RIGHT PARENTHESIS
* - name: ASTERISK
+ - name: PLUS SIGN
, - name: COMMA
- - name: HYPHEN-MINUS
. - name: FULL STOP
/ - name: SOLIDUS
0 - name: DIGIT ZERO
1 - name: DIGIT ONE
2 - name: DIGIT TWO
3 - name: DIGIT THREE
4 - name: DIGIT FOUR
5 - name: DIGIT FIVE
6 - name: DIGIT SIX
7 - name: DIGIT SEVEN
8 - name: DIGIT EIGHT
9 - name: DIGIT NINE
: - name: COLON
; - name: SEMICOLON
- name: LESS-THAN SIGN
= - name: EQUALS SIGN
- name: GREATER-THAN SIGN
? - name: QUESTION MARK
@ - name: COMMERCIAL AT
A - name: LATIN CAPITAL LETTER A
B - name: LATIN CAPITAL LETTER B
C - name: LATIN CAPITAL LETTER C
D - name: LATIN CAPITAL LETTER D
E - name: LATIN CAPITAL LETTER E
F - name: LATIN CAPITAL LETTER F
G - name: LATIN CAPITAL LETTER G
H - name: LATIN CAPITAL LETTER H
I - name: LATIN CAPITAL LETTER I
J - name: LATIN CAPITAL LETTER J
K - name: LATIN CAPITAL LETTER K
L - name: LATIN CAPITAL LETTER L
M - name: LATIN CAPITAL LETTER M
N - name: LATIN CAPITAL LETTER N
O - name: LATIN CAPITAL LETTER O
P - name: LATIN CAPITAL LETTER P
Q - name: LATIN CAPITAL LETTER Q
R - name: LATIN CAPITAL LETTER R
S - name: LATIN CAPITAL LETTER S
T - name: LATIN CAPITAL LETTER T
U - name: LATIN CAPITAL LETTER U
V - name: LATIN CAPITAL LETTER V
W - name: LATIN CAPITAL LETTER W
X - name: LATIN CAPITAL LETTER X
Y - name: LATIN CAPITAL LETTER Y
Z - name: LATIN CAPITAL LETTER Z
[ - name: LEFT SQUARE BRACKET
\ - name: REVERSE SOLIDUS
] - name: RIGHT SQUARE BRACKET
^ - name: CIRCUMFLEX ACCENT
_ - name: LOW LINE
` - name: GRAVE ACCENT
a - name: LATIN SMALL LETTER A
b - name: LATIN SMALL LETTER B
c - name: LATIN SMALL LETTER C
d - name: LATIN SMALL LETTER D
e - name: LATIN SMALL LETTER E
f - name: LATIN SMALL LETTER F
g - name: LATIN SMALL LETTER G
h - name: LATIN SMALL LETTER H
i - name: LATIN SMALL LETTER I
j - name: LATIN SMALL LETTER J
k - name: LATIN SMALL LETTER K
l - name: LATIN SMALL LETTER L
m - name: LATIN SMALL LETTER M
n - name: LATIN SMALL LETTER N
o - name: LATIN SMALL LETTER O
p - name: LATIN SMALL LETTER P
q - name: LATIN SMALL LETTER Q
r - name: LATIN SMALL LETTER R
s - name: LATIN SMALL LETTER S
t - name: LATIN SMALL LETTER T
u - name: LATIN SMALL LETTER U
v - name: LATIN SMALL LETTER V
w - name: LATIN SMALL LETTER W
x - name: LATIN SMALL LETTER X
y - name: LATIN SMALL LETTER Y
z - name: LATIN SMALL LETTER Z
{ - name: LEFT CURLY BRACKET
| - name: VERTICAL LINE
} - name: RIGHT CURLY BRACKET
~ - name: TILDE
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.080
s
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847592#comment-17847592
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118989898
Naive upstream solution:
https://github.com/codehaus-plexus/plexus-xml/pull/28
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would be affected by it would already have
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847590#comment-17847590
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118981114
With `StringEscapeUtils`:
```
NULL: START
OF HEADING: START OF TEXT: END OF TEXT:
END OF TRANSMISSION: ENQUIRY:
ACKNOWLEDGE: BELL: BACKSPACE:
CHARACTER TABULATION: LINE FEED (LF):
LINE TABULATION: FORM FEED (FF):
CARRIAGE RETURN (CR):
SHIFT OUT: SHIFT IN: DATA LINK
ESCAPE: DEVICE CONTROL ONE: DEVICE CONTROL TWO:
DEVICE CONTROL THREE: DEVICE CONTROL FOUR:
NEGATIVE ACKNOWLEDGE: SYNCHRONOUS IDLE:
END OF TRANSMISSION BLOCK: CANCEL: END
OF MEDIUM: SUBSTITUTE: ESCAPE:
INFORMATION SEPARATOR FOUR: INFORMATION SEPARATOR
THREE: INFORMATION SEPARATOR TWO: INFORMATION
SEPARATOR ONE: SPACE: EXCLAMATION MARK:
!QUOTATION MARK: quot;NUMBER SIGN:
#DOLLAR SIGN: $PERCENT SIGN: %AMPERSAND:
amp;APOSTROPHE: apos;LEFT PARENTHESIS:
(RIGHT PARENTHESIS: )ASTERISK: *PLUS
SIGN: +COMMA: ,HYPHEN-MINUS: -FULL STOP:
.SOLIDUS: /DIGIT ZERO: 0DIGIT ONE:
1DIGIT TWO: 2DIGIT THREE: 3DIGIT FOUR:
4DIGIT FIVE: 5DIGIT SIX: 6DIGIT SEVEN:
7DIGIT EIGHT: 8DIGIT NINE: 9COLON:
:SEMICOLON: ;LESS-THAN SIGN:
lt;EQUALS SIGN: =GREATER-THAN SIGN:
gt;QUESTION MARK: ?COMMERCIAL AT:
@LATIN CAPITAL LETTER A: ALATIN CAPITAL LETTER B:
BLATIN CAPITAL LETTER C: CLATIN CAPITAL LETTER D:
DLATIN CAPITAL LETTER E: ELATIN CAPITAL LETTER F:
FLATIN CAPITAL LETTER G: GLATIN CAPITAL LETTER H:
HLATIN CAPITAL LETTER I: ILATIN CAPITAL LETTER J:
JLATIN CAPITAL LETTER K: KLATIN CAPITAL LETTER L:
LLATIN CAPITAL LETTER M: MLATIN CAPITAL LETTER N:
NLATIN CAPITAL LETTER O: OLATIN CAPITAL LETTER P:
PLATIN CAPITAL LETTER Q: QLATIN CAPITAL LETTER R:
RLATIN CAPITAL LETTER S: SLATIN CAPITAL LETTER T:
TLATIN CAPITAL LETTER U: ULATIN CAPITAL LETTER V:
VLATIN CAPITAL LETTER W: WLATIN CAPITAL LETTER X:
XLATIN CAPITAL LETTER Y: YLATIN CAPITAL LETTER Z:
ZLEFT SQUARE BRACKET: [REVERSE SOLIDUS:
\RIGHT SQUARE BRACKET: ]CIRCUMFLEX ACCENT:
^LOW LINE: _GRAVE ACCENT: `LATIN SMALL
LETTER A: aLATIN SMALL LETTER B: bLATIN SMALL LETTER
C: cLATIN SMALL LETTER D: dLATIN SMALL LETTER E:
eLATIN SMALL LETTER F: fLATIN SMALL LETTER G:
gLATIN SMALL LETTER H: hLATIN SMALL LETTER I:
iLATIN SMALL LETTER J: jLATIN SMALL LETTER K:
kLATIN SMALL LETTER L: lLATIN SMALL LETTER M:
mLATIN SMALL LETTER N: nLATIN SMALL LETTER O:
oLATIN SMALL LETTER P: pLATIN SMALL LETTER Q:
qLATIN SMALL LETTER R: rLATIN SMALL LETTER S:
sLATIN SMALL LETTER T: tLATIN SMALL LETTER U:
uLATIN SMALL LETTER V: vLATIN SMALL LETTER W:
wLATIN SMALL LETTER X: xLATIN SMALL LETTER Y:
yLATIN SMALL LETTER Z: zLEFT CURLY BRACKET:
{VERTICAL LINE: |RIGHT CURLY BRACKET:
}TILDE: ~
```
I believe they are broken as well.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847587#comment-17847587
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118979631
Counterpart with Plexus:
```
MXSerializer sr = new MXSerializer();
sr.setOutput(System.out, "UTF-8");
sr.startDocument(null, Boolean.TRUE);
sr.startTag(null, "root");
for (int i = 0; i < Byte.MAX_VALUE; i++) {
sr.startTag(null, "char");
sr.text(Character.getName(i) + ": " + ((char) i));
sr.endTag(null, "char");
}
sr.endTag(null, "root");
sr.endDocument();
```
output:
```
Exception in thread "main" java.lang.IllegalStateException: character 0 is
not allowed in output
at
org.codehaus.plexus.util.xml.pull.MXSerializer.writeElementContent(MXSerializer.java:947)
at
org.codehaus.plexus.util.xml.pull.MXSerializer.text(MXSerializer.java:780)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.main(DefaultSiteRenderer.java:955)
```
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847586#comment-17847586
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118973031
@elharo is right. This is how it should look like:
```java
public static void main(String[] args) throws
ParserConfigurationException, TransformerException {
Document doc =
DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
Element root = doc.createElement("root");
for (int i = 0; i < Byte.MAX_VALUE; i++) {
Element elem = doc.createElement("char");
elem.setTextContent(Character.getName(i) + ": " +
((char) i));
root.appendChild(elem);
}
doc.appendChild(root);
DOMSource domSource = new DOMSource(doc);
StreamResult result = new StreamResult(System.out);
TransformerFactory tf = TransformerFactory.newInstance();
Transformer transformer = tf.newTransformer();
transformer.setOutputProperty(OutputKeys.INDENT, "yes");
transformer.setOutputProperty("{http://xml.apache.org/xslt}indent-amount;, "2");
transformer.transform(domSource, result);
}
```
output:
```
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
details.
NULL:
START OF HEADING:
START OF TEXT:
END OF TEXT:
END OF TRANSMISSION:
ENQUIRY:
ACKNOWLEDGE:
BELL:
BACKSPACE:
CHARACTER TABULATION:
LINE FEED (LF):
LINE TABULATION:
FORM FEED (FF):
CARRIAGE RETURN (CR):
SHIFT OUT:
SHIFT IN:
DATA LINK ESCAPE:
DEVICE CONTROL ONE:
DEVICE CONTROL TWO:
DEVICE CONTROL THREE:
DEVICE CONTROL FOUR:
NEGATIVE ACKNOWLEDGE:
SYNCHRONOUS IDLE:
END OF TRANSMISSION BLOCK:
CANCEL:
END OF MEDIUM:
SUBSTITUTE:
ESCAPE:
INFORMATION SEPARATOR FOUR:
INFORMATION SEPARATOR THREE:
INFORMATION SEPARATOR TWO:
INFORMATION SEPARATOR ONE:
SPACE:
EXCLAMATION MARK: !
QUOTATION MARK: "
NUMBER SIGN: #
DOLLAR SIGN: $
PERCENT SIGN: %
AMPERSAND:
APOSTROPHE: '
LEFT PARENTHESIS: (
RIGHT PARENTHESIS: )
ASTERISK: *
PLUS SIGN: +
COMMA: ,
HYPHEN-MINUS: -
FULL STOP: .
SOLIDUS: /
DIGIT ZERO: 0
DIGIT ONE: 1
DIGIT TWO: 2
DIGIT THREE: 3
DIGIT FOUR: 4
DIGIT FIVE: 5
DIGIT SIX: 6
DIGIT SEVEN: 7
DIGIT EIGHT: 8
DIGIT NINE: 9
COLON: :
SEMICOLON: ;
LESS-THAN SIGN:
EQUALS SIGN: =
GREATER-THAN SIGN:
QUESTION MARK: ?
COMMERCIAL AT: @
LATIN CAPITAL LETTER A: A
LATIN CAPITAL LETTER B: B
LATIN CAPITAL LETTER C: C
LATIN CAPITAL LETTER D: D
LATIN CAPITAL LETTER E: E
LATIN CAPITAL LETTER F: F
LATIN CAPITAL LETTER G: G
LATIN CAPITAL LETTER H: H
LATIN CAPITAL LETTER I: I
LATIN CAPITAL LETTER J: J
LATIN CAPITAL LETTER K: K
LATIN CAPITAL LETTER L: L
LATIN CAPITAL LETTER M: M
LATIN CAPITAL LETTER N: N
LATIN CAPITAL LETTER O: O
LATIN CAPITAL LETTER P: P
LATIN CAPITAL LETTER Q: Q
LATIN CAPITAL LETTER R: R
LATIN CAPITAL LETTER S: S
LATIN CAPITAL LETTER T: T
LATIN CAPITAL LETTER U: U
LATIN CAPITAL LETTER V: V
LATIN CAPITAL LETTER W: W
LATIN CAPITAL LETTER X: X
LATIN CAPITAL LETTER Y: Y
LATIN CAPITAL LETTER Z: Z
LEFT SQUARE BRACKET: [
REVERSE SOLIDUS: \
RIGHT SQUARE BRACKET: ]
CIRCUMFLEX ACCENT: ^
LOW LINE: _
GRAVE ACCENT: `
LATIN SMALL LETTER A: a
LATIN SMALL LETTER B: b
LATIN SMALL LETTER C: c
LATIN SMALL LETTER D: d
LATIN SMALL LETTER E: e
LATIN SMALL LETTER F: f
LATIN SMALL LETTER G: g
LATIN SMALL LETTER H: h
LATIN SMALL LETTER I: i
LATIN SMALL LETTER J: j
LATIN SMALL LETTER K: k
LATIN SMALL LETTER L: l
LATIN SMALL LETTER M: m
LATIN SMALL LETTER N: n
LATIN SMALL LETTER O: o
LATIN SMALL LETTER P: p
LATIN SMALL LETTER Q: q
LATIN SMALL LETTER R: r
LATIN SMALL LETTER S: s
LATIN SMALL LETTER T: t
LATIN SMALL LETTER U: u
LATIN SMALL LETTER V: v
LATIN SMALL LETTER W: w
LATIN SMALL LETTER X: x
LATIN SMALL LETTER Y: y
LATIN SMALL LETTER Z: z
LEFT CURLY BRACKET: {
VERTICAL LINE: |
RIGHT CURLY BRACKET: }
TILDE: ~
```
which it does not with the
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847571#comment-17847571
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1605818675
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1640,7 +1642,7 @@ private void runBuild(
}
} catch (RunFailureException e) {
buildJob.setResult(e.getType());
-buildJob.setFailureMessage(e.getMessage());
+
buildJob.setFailureMessage(StringEscapeUtils.escapeXml10(e.getMessage()));
Review Comment:
> Assuming buildJob is just an object that contains strings and other
things, but has no particular XML internals (like 99.9% of classes that contain
strings) nothing inside it should be escaped.
>
> Ideally the XML writer should escape strings when it needs to. Or is the
XML writer is broken and won't do that, then the escaping should be done after
the string is extracted from the buildJob and before it's passed to the writer.
Escaping strings inside the buildJob breaks its semantics and tightly couples
all the classes together in one particularly brittle path.
Yes, the XML writer is broken and needs an issue.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847528#comment-17847528
]
ASF GitHub Bot commented on MINVOKER-351:
-
elharo commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1605791199
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1640,7 +1642,7 @@ private void runBuild(
}
} catch (RunFailureException e) {
buildJob.setResult(e.getType());
-buildJob.setFailureMessage(e.getMessage());
+
buildJob.setFailureMessage(StringEscapeUtils.escapeXml10(e.getMessage()));
Review Comment:
Assuming buildJob is just an object that contains strings and other things,
but has no particular XML internals (like 99.9% of classes that contain
strings) nothing inside it should be escaped.
Ideally the XML writer should escape strings when it needs to. Or is the XML
writer is broken and won't do that, then the escaping should be done after the
string is extracted from the buildJob and before it's passed to the writer.
Escaping strings inside the buildJob breaks its semantics and tightly couples
all the classes together in one particularly brittle path.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847515#comment-17847515
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118810846
@michael-o IT improved according to hints
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would be affected by it would already have unparseable JUnit reports.
> * I
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847513#comment-17847513
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1605783758
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1640,7 +1642,7 @@ private void runBuild(
}
} catch (RunFailureException e) {
buildJob.setResult(e.getType());
-buildJob.setFailureMessage(e.getMessage());
+
buildJob.setFailureMessage(StringEscapeUtils.escapeXml10(e.getMessage()));
Review Comment:
In other place message is produced in code and we sure that does not
contains special chars.
Only `exception.getMessage()` can return everything
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}}
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847509#comment-17847509
]
Michael Osipov commented on MINVOKER-351:
-
The behavior is inconsitent because plugins are a moving target. One must pin
all relevant plugins otherwise the behavior will vary.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would be affected by it would already have unparseable JUnit reports.
> * I _believe_ that Java's {{j.u.r.Pattern}}
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847508#comment-17847508
]
Mikkel Kjeldsen commented on MINVOKER-351:
--
{quote}
So this output shows a lot of problems:
* You failed to provide the conditions: Maven version, Java version, plugin
versions
* The test requires Java 11, what for? Is that a JAva version specific issue?
* The IT passes with Maven 3.8.x, but fails with 3.9.x.
* Important plugins haven't been pinned
{quote}
The behavior in Maven 3.8.x is interesting because it suggests a different
error in the test execution: it claims to run the test yet reports 0 tests run,
which could well explain the missing output. I can see the class being compiled
but I am unable to glean from the output of {{-Dinvoker.debug}} whether it
confirms that hypothesis.
In any case, I suspect this is just an artifact of using JUnit 5. Maven 3.6.3
and up combined with [m-surefire-p
2.22.0|https://blogsarchive.apache.org/maven/entry/apache-maven-surefire-plugin-2]
and up behave as expected, while m-surefire-p 2.21.0 in the same versions of
Maven fail to produce the expected output. Perhaps because of SUREFIRE-1330.
Besides this, under the reasonable assumption that no exceptional branching for
these component versions occurs, the versions of
* Java
* Maven
* Surefire
have no bearing on the behavior of m-invoker-p's callstacks, which ultimately
and independently end up producing insufficiently sanitized output. The
question is only whether to...
# ignore the issue
# fix the issue locally inside m-invoker-p
# punt the issue upstream to the writer
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847442#comment-17847442
]
ASF GitHub Bot commented on MINVOKER-351:
-
elharo commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1605514887
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1640,7 +1642,7 @@ private void runBuild(
}
} catch (RunFailureException e) {
buildJob.setResult(e.getType());
-buildJob.setFailureMessage(e.getMessage());
+
buildJob.setFailureMessage(StringEscapeUtils.escapeXml10(e.getMessage()));
Review Comment:
I probably need to pop the code open to figure this out. What is "buildJob"?
It's a org.apache.maven.plugins.invoker.model.BuildJob, right? If so, why does
it need escaped XML test instead of just plain text? I'd expect it to supply
unescaped strings to the writer which would then do any necessary escaping.
In line 1639 above, the message is not escaped. It should likely be escaped
in both or neither.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847428#comment-17847428
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118247404
Please also prepend:
https://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#getName%28int%29
Then we know what we print out.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847426#comment-17847426
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118242573
@slawekjaranowski Please ping compiler and surefire plugin in the embedded
IT, that's the reason why there is no output.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
>
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847425#comment-17847425
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118239187
@slawekjaranowski Just ran the changed IT with 3.8.8 and 3.9.6. In 3.8.8 I
don't see output from 0x00 to 0x0F at all in `build.log`. Regardless of the
escaping you applied. There is some inherent bug here which I prefer to
understand first because applying this change.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847409#comment-17847409
]
Slawomir Jaranowski commented on MINVOKER-351:
--
Please look at test in my PR, I modified it a little then when was proposed in
attachment.
* remove JDK 11 reqirement
* pin used plugin version site and surefire
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would be affected by it would already have unparseable JUnit reports.
> * I
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847405#comment-17847405
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118180697
> > Moving to draft because the IT is poorly designed.
>
> I hope you want to redesign proposed IT or you have any other hints how
should be done.
It is rather the conditions the IT comes into play. Please read my analysis
on the JIRA issue.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847401#comment-17847401
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118165742
> Moving to draft because the IT is poorly designed.
I hope you want to redesign proposed IT or you have any other hints how
should be done.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible,
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847398#comment-17847398
]
Michael Osipov commented on MINVOKER-351:
-
So this output shows a lot of problems:
* You failed to provide the conditions: Maven version, Java version, plugin
versions
* The test requires Java 11, what for? Is that a JAva version specific issue?
* The IT passes with Maven 3.8.x, but fails with 3.9.x.
* Important plugins haven't been pinned
When I diff the build log with Maven 3.8.x:
{noformat}
---
T E S T S
---
Running example.minvoker351.ExampleTest
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
{noformat}
with 3.9.6:
{noformat}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running example.minvoker351.ExampleTest
null
!
"
#
$
%
&
'
(
)
*
+
,
-
.
/
0
1
2
3
4
5
6
7
8
9
:
;
<
=
>
?
@
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
[
\
]
^
_
`
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
r
s
t
u
v
w
x
y
z
{
|
}
~
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.078 s
-- in example.minvoker351.ExampleTest
[INFO]
{noformat}
I have clearly to see this requires more analysis.
[~cstamas], do you remember that we had problems with Plexus Utils with XML
parsing it had regressions compared to 3.8.x. This could be yet another
regression.
I think we need understand the cause better before we can identify where to
apply a proper fix.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
>
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847395#comment-17847395
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2118154917
Moving to draft because the IT is poorly designed.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would be affected by it would already have unparseable JUnit reports.
> *
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847368#comment-17847368
]
Mikkel Kjeldsen commented on MINVOKER-351:
--
[~michael-o], curious output. This is the expected output:
{noformat}
~ $ cd $(mktemp -d)
/tmp/tmp.0HU4NpMJCX $ wget --quiet
https://issues.apache.org/jira/secure/attachment/13068809/minvoker-351.tar.gz
/tmp/tmp.0HU4NpMJCX $ tar vxf minvoker-351.tar.gz
minvoker-351/
minvoker-351/pom.xml
minvoker-351/src/
minvoker-351/src/it/
minvoker-351/src/it/minvoker-351/
minvoker-351/src/it/minvoker-351/pom.xml
minvoker-351/src/it/minvoker-351/src/
minvoker-351/src/it/minvoker-351/src/test/
minvoker-351/src/it/minvoker-351/src/test/java/
minvoker-351/src/it/minvoker-351/src/test/java/example/
minvoker-351/src/it/minvoker-351/src/test/java/example/minvoker351/
minvoker-351/src/it/minvoker-351/src/test/java/example/minvoker351/ExampleTest.java
minvoker-351/src/it/minvoker-351/src/main/
minvoker-351/src/it/minvoker-351/src/main/java/
minvoker-351/src/it/minvoker-351/src/main/java/example/
minvoker-351/src/it/minvoker-351/src/main/java/example/minvoker351/
minvoker-351/src/it/minvoker-351/src/main/java/example/minvoker351/Example.java
/tmp/tmp.0HU4NpMJCX $ cd minvoker-351/
/tmp/tmp.0HU4NpMJCX/minvoker-351 $ mvn --version
Apache Maven 3.9.6
Maven home: /usr/share/maven
Java version: 21.0.2, vendor: N/A, runtime: /usr/lib64/jvm/java-21-openjdk-21
Default locale: en_DK, platform encoding: UTF-8
OS name: "linux", version: "5.14.21-150500.55.52-default", arch: "amd64",
family: "unix"
/tmp/tmp.0HU4NpMJCX/minvoker-351 $ mvn verify site
[INFO] Scanning for projects...
[INFO]
[INFO] --< example.minvoker351:minvoker-351 >--
[INFO] Building minvoker-351 1.0-SNAPSHOT
[INFO] from pom.xml
[INFO] [ jar ]-
[INFO]
[INFO] --- resources:3.3.1:resources (default-resources) @ minvoker-351 ---
[INFO] skip non existing resourceDirectory
/tmp/tmp.0HU4NpMJCX/minvoker-351/src/main/resources
[INFO]
[INFO] --- compiler:3.11.0:compile (default-compile) @ minvoker-351 ---
[INFO] No sources to compile
[INFO]
[INFO] --- resources:3.3.1:testResources (default-testResources) @ minvoker-351
---
[INFO] skip non existing resourceDirectory
/tmp/tmp.0HU4NpMJCX/minvoker-351/src/test/resources
[INFO]
[INFO] --- compiler:3.11.0:testCompile (default-testCompile) @ minvoker-351 ---
[INFO] No sources to compile
[INFO]
[INFO] --- surefire:3.2.2:test (default-test) @ minvoker-351 ---
[INFO] No tests to run.
[INFO]
[INFO] --- jar:3.3.0:jar (default-jar) @ minvoker-351 ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar:
/tmp/tmp.0HU4NpMJCX/minvoker-351/target/minvoker-351-1.0-SNAPSHOT.jar
[INFO]
[INFO] --- invoker:3.6.1:install (integration-test) @ minvoker-351 ---
[INFO] Installing
/tmp/tmp.0HU4NpMJCX/minvoker-351/target/minvoker-351-1.0-SNAPSHOT.jar to
/tmp/tmp.0HU4NpMJCX/minvoker-351/target/local-repo/example/minvoker351/minvoker-351/1.0-SNAPSHOT/minvoker-351-1.0-SNAPSHOT.jar
[INFO] Installing /tmp/tmp.0HU4NpMJCX/minvoker-351/pom.xml to
/tmp/tmp.0HU4NpMJCX/minvoker-351/target/local-repo/example/minvoker351/minvoker-351/1.0-SNAPSHOT/minvoker-351-1.0-SNAPSHOT.pom
[INFO]
[INFO] --- invoker:3.6.1:run (integration-test) @ minvoker-351 ---
[INFO] Building: minvoker-351/pom.xml
[INFO] minvoker-351/pom.xml . SUCCESS
(6.021 s)
[INFO] -
[INFO] Build Summary:
[INFO] Passed: 1, Failed: 0, Errors: 0, Skipped: 0
[INFO] -
[INFO]
[INFO] --- site:3.12.1:site (default-site) @ minvoker-351 ---
[INFO] configuring report plugin
org.apache.maven.plugins:maven-project-info-reports-plugin:3.5.0
[INFO] 15 reports detected for maven-project-info-reports-plugin:3.5.0:
ci-management, dependencies, dependency-info, dependency-management,
distribution-management, index, issue-management, licenses, mailing-lists,
modules, plugin-management, plugins, scm, summary, team
[INFO] configuring report plugin
org.apache.maven.plugins:maven-surefire-report-plugin:3.2.5
[INFO] preparing maven-surefire-report-plugin:report report requires
'[surefire]test' forked phase execution
[INFO]
[INFO] >>> surefire-report:3.2.5:report > [surefire]test @ minvoker-351 >>>
[INFO]
[INFO] --- resources:3.3.1:resources (default-resources) @ minvoker-351 ---
[INFO] skip non existing resourceDirectory
/tmp/tmp.0HU4NpMJCX/minvoker-351/src/main/resources
[INFO]
[INFO] --- compiler:3.11.0:compile (default-compile) @ minvoker-351 ---
[INFO] No sources to compile
[INFO]
[INFO] --- resources:3.3.1:testResources (default-testResources) @ minvoker-351
---
[INFO] skip non existing resourceDirectory
/tmp/tmp.0HU4NpMJCX/minvoker-351/src/test/resources
[INFO]
[INFO] ---
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847328#comment-17847328
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117684010
> > As we see root cause is in plexus-xml I know that using escapeXml10 is a
workaround here.
> > So what is your proposition to solve issue in m-invoker-p?
> > @michael-o @elharo
>
> Regardless of the fix or the flaw in Plexus XML I completely fail to
understand the supplied reprocuder in the JIRA issue.
Ok.
- we execute m-invoker-p for project `src/it/MINVOKER-351`
- m-invoker-p - execute a project
`src/it/MINVOKER-351/src/it/minvoker-351`
- in `src/it/MINVOKER-351/src/it/minvoker-351` we have a unit test
which print some special chars to build output
- m-invoker-p - collect output of
`src/it/MINVOKER-351/src/it/minvoker-351` and store in buildlog file
- m-invoker-p - generate a junit report with `systemOut` element which
contains body of buildlog file
- execute `site-plugin` with `surefire-report` to confirm that generated
junit reports are ok
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847291#comment-17847291
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117611998
> As we see root cause is in plexus-xml I know that using escapeXml10 is a
workaround here.
>
> So what is your proposition to solve issue in m-invoker-p?
>
> @michael-o @elharo
Regardless of the fix or the flaw in Plexus XML I completely fail to
understand the supplied reprocuder in the JIRA issue.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847289#comment-17847289
]
Michael Osipov commented on MINVOKER-351:
-
[~mkjeldsen], beat me, but I don't see the failure:
{noformat}
D:\Entwicklung\Projekte\minvoker-351> mvn clean verify site
[INFO] Scanning for projects...
[INFO]
[INFO] --< example.minvoker351:minvoker-351 >--
[INFO] Building minvoker-351 1.0-SNAPSHOT
[INFO] from pom.xml
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ minvoker-351 ---
[INFO] Deleting D:\Entwicklung\Projekte\minvoker-351\target
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
minvoker-351 ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
D:\Entwicklung\Projekte\minvoker-351\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ minvoker-351
---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
minvoker-351 ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
D:\Entwicklung\Projekte\minvoker-351\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
minvoker-351 ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ minvoker-351 ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ minvoker-351 ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar:
D:\Entwicklung\Projekte\minvoker-351\target\minvoker-351-1.0-SNAPSHOT.jar
[INFO]
[INFO] --- maven-invoker-plugin:3.6.1:install (integration-test) @ minvoker-351
---
[INFO] Installing
D:\Entwicklung\Projekte\minvoker-351\target\minvoker-351-1.0-SNAPSHOT.jar to
D:\Entwicklung\Projekte\minvoker-351\target\local-repo\example\minvoker351\minvoker-351\1.0-SNAPSHOT\minvoker-351-1.0-SNAPSHOT.jar
[INFO] Installing D:\Entwicklung\Projekte\minvoker-351\pom.xml to
D:\Entwicklung\Projekte\minvoker-351\target\local-repo\example\minvoker351\minvoker-351\1.0-SNAPSHOT\minvoker-351-1.0-SNAPSHOT.pom
[INFO]
[INFO] --- maven-invoker-plugin:3.6.1:run (integration-test) @ minvoker-351 ---
[INFO] Building: minvoker-351\pom.xml
[INFO] minvoker-351\pom.xml . SUCCESS
(15.12 s)
[INFO] -
[INFO] Build Summary:
[INFO] Passed: 1, Failed: 0, Errors: 0, Skipped: 0
[INFO] -
[INFO]
[INFO] --- maven-site-plugin:3.12.1:site (default-site) @ minvoker-351 ---
[INFO] configuring report plugin
org.apache.maven.plugins:maven-project-info-reports-plugin:3.5.0
[INFO] 15 reports detected for maven-project-info-reports-plugin:3.5.0:
ci-management, dependencies, dependency-info, dependency-management,
distribution-management, index, issue-management, licenses, mailing-lists,
modules, plugin-management, plugins, scm, summary, team
[INFO] configuring report plugin
org.apache.maven.plugins:maven-surefire-report-plugin:3.2.5
[INFO] preparing maven-surefire-report-plugin:report report requires
'[surefire]test' forked phase execution
[INFO]
[INFO] >>> maven-surefire-report-plugin:3.2.5:report > [surefire]test @
minvoker-351 >>>
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
minvoker-351 ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
D:\Entwicklung\Projekte\minvoker-351\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ minvoker-351
---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
minvoker-351 ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
D:\Entwicklung\Projekte\minvoker-351\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
minvoker-351 ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ minvoker-351 ---
[INFO] No tests to run.
[INFO] Skipping execution of surefire because it has already been run for this
configuration
[INFO]
[INFO] <<< maven-surefire-report-plugin:3.2.5:report < [surefire]test @
minvoker-351 <<<
[INFO]
[INFO] '[surefire]test' forked phase execution for
maven-surefire-report-plugin:report report preparation done
[INFO] 3 reports detected for maven-surefire-report-plugin:3.2.5:
failsafe-report-only, report, report-only
[INFO] Rendering site with default locale English (en)
[WARNING] No project URL defined - decoration links will not be relativized!
[INFO] Rendering
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847278#comment-17847278
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117538380
As we see root cause is in plexus-xml
I know that using escapeXml10 is a workaround here.
So what is your proposition to solve issue in m-invoker-p?
@michael-o @elharo
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847269#comment-17847269
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1604933590
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1640,7 +1642,7 @@ private void runBuild(
}
} catch (RunFailureException e) {
buildJob.setResult(e.getType());
-buildJob.setFailureMessage(e.getMessage());
+
buildJob.setFailureMessage(StringEscapeUtils.escapeXml10(e.getMessage()));
Review Comment:
`buildJob` is class generated by modello internally `MXSerializer` is used
Also here exception is generated by post-build scrip and message contains
output of it it also be everything
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847268#comment-17847268
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1604929130
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1779,7 +1781,7 @@ private void writeJunitReport(BuildJob buildJob, String
safeFileName) throws Moj
if (buildLogFile != null && buildLogFile.exists()) {
getLog().debug("fileLogger:" + buildLogFile);
try {
-systemOut.setValue(FileUtils.fileRead(buildLogFile));
+
systemOut.setValue(StringEscapeUtils.escapeXml10(FileUtils.fileRead(buildLogFile)));
Review Comment:
`buildLogFile` contains raw output of tested Maven project so can contain
everything.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847255#comment-17847255
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1604905596
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1779,7 +1781,7 @@ private void writeJunitReport(BuildJob buildJob, String
safeFileName) throws Moj
if (buildLogFile != null && buildLogFile.exists()) {
getLog().debug("fileLogger:" + buildLogFile);
try {
-systemOut.setValue(FileUtils.fileRead(buildLogFile));
+
systemOut.setValue(StringEscapeUtils.escapeXml10(FileUtils.fileRead(buildLogFile)));
Review Comment:
`value` is a `String`, that's it.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}}
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847248#comment-17847248
]
ASF GitHub Bot commented on MINVOKER-351:
-
elharo commented on code in PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#discussion_r1604812464
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1779,7 +1781,7 @@ private void writeJunitReport(BuildJob buildJob, String
safeFileName) throws Moj
if (buildLogFile != null && buildLogFile.exists()) {
getLog().debug("fileLogger:" + buildLogFile);
try {
-systemOut.setValue(FileUtils.fileRead(buildLogFile));
+
systemOut.setValue(StringEscapeUtils.escapeXml10(FileUtils.fileRead(buildLogFile)));
Review Comment:
One thing I don't yet understand is what the "value" being set here is in
Xpp3Dom. I *think* (could be wrong) it's supposed to be the raw text to be
output, which means Xpp3Dom is in fact not a document object model at all. The
confusion between object model and serialized form is a real problem with
Xpp3Dom.
##
src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java:
##
@@ -1640,7 +1642,7 @@ private void runBuild(
}
} catch (RunFailureException e) {
buildJob.setResult(e.getType());
-buildJob.setFailureMessage(e.getMessage());
+
buildJob.setFailureMessage(StringEscapeUtils.escapeXml10(e.getMessage()));
Review Comment:
I haven't followed through the complete code yet, but the failure message
should generally only be escaped once, and that should be left to the XML
writer. That is, don't escape a string that appears in PCDATA or an attribute
value. Let the writer do that.
This all assumes that the writer does correctly escape everything. Some
libraries have borked this up in one way or another. Looking at it now
Xpp3DomWriter is a mess and doesn't have a clean model of when and what to
escape. It seems to confuse the unescaped model strings with the serialized
escaped strings, and switches back and forth between escaped or not depending
on switches.
I'm not sure exactly how to fix this issue. Really what needs to happen is
either fix XPP3DomWriter and likely XPPDom, while breaking the API and all
existing dependents, or switch to a better designed XML library here. Short of
that maybe you can make this work with enough unit tests.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847242#comment-17847242
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117348780
> > Am I stupid or where am I supposed to find the output of `new
Example().printAscii();`? I can't find it.
>
> There is:
>
> ```
> public class Example {
> public void printAscii() {
> for (int i = 0; i < Byte.MAX_VALUE; ++i) {
> System.out.println((char) i);
> }
> }
> ```
>
> Standard output of test is pass to log file and next to report
I know, but I don't see that stdout anywhere.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847239#comment-17847239
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117343495
> Am I stupid or where am I supposed to find the output of `new
Example().printAscii();`? I can't find it.
There is:
```
public class Example {
public void printAscii() {
for (int i = 0; i < Byte.MAX_VALUE; ++i) {
System.out.println((char) i);
}
}
```
Standard output of test is pass to log file and next to report
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847238#comment-17847238
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117322332
Am I stupid or where am I supposed to find the output of `new
Example().printAscii();`? I can't find it.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would be affected
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847237#comment-17847237
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117316468
> > Looking into this. Can we make sure that we do not double escape the
five protected chars.
>
> I used:
>
> ```
> Xpp3DomWriter.write(new PrettyPrintXMLWriter(osw), testsuite, false);
> ```
>
> so escaping is turned off in `Xpp3DomWriter`
Maybe you should add a comment in the source code to depict this.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847234#comment-17847234
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117302002
> Looking into this. Can we make sure that we do not double escape the five
protected chars.
I used:
```
Xpp3DomWriter.write(new PrettyPrintXMLWriter(osw), testsuite, false);
```
so escaping is turned off in `Xpp3DomWriter`
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847235#comment-17847235
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117302200
@elharo Should an XML writer escape invalid chars to entities or fail here?
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would be affected by it would already have
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847232#comment-17847232
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117297043
Looking into this. Can we make sure that we do not double escape the five
protected chars.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would be affected by it would
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847233#comment-17847233
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117298481
when we will use MXSerializer we will have a exception ... so special
characters should be somehow filtered
https://github.com/codehaus-plexus/plexus-xml/blob/master/src/main/java/org/codehaus/plexus/util/xml/pull/MXSerializer.java#L937-L958
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847229#comment-17847229
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117281962
Exactly similar implementation should be in plexus-xml
https://github.com/codehaus-plexus/plexus-xml/blob/master/src/main/java/org/codehaus/plexus/util/xml/PrettyPrintXMLWriter.java#L205-L222
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847228#comment-17847228
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117272933
...obviously it is:
https://github.com/apache/commons-text/blob/46c7a93ed0b3e43c369d89d15495fb2bce0e693b/src/main/java/org/apache/commons/text/StringEscapeUtils.java#L232-L274
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847226#comment-17847226
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2117269068
Read the JIRA issue. I assume we are talking about chars outside of
https://en.wikipedia.org/wiki/Valid_characters_in_XML#XML_1.0?
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847192#comment-17847192
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2116953180
> @michael-o there is a problem with special chars ... they are not escaped
/ removed by the plexus-xml
Is there an upstream issue for this?
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847101#comment-17847101
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2116213655
@michael-o there is a problem with special chars ... they are not escaped /
removed by the plexus-xml
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847094#comment-17847094
]
ASF GitHub Bot commented on MINVOKER-351:
-
michael-o commented on PR #242:
URL:
https://github.com/apache/maven-invoker-plugin/pull/242#issuecomment-2116149385
I don't understand this because it looks logically wrong. The model does not
care how it is marshaled, shouldn't the XML writer do this?
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847089#comment-17847089
]
ASF GitHub Bot commented on MINVOKER-351:
-
slawekjaranowski opened a new pull request, #242:
URL: https://github.com/apache/maven-invoker-plugin/pull/242
- use StringEscapeUtils.escapeXml10 form commons-text
https://issues.apache.org/jira/browse/MINVOKER-351
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Mikkel Kjeldsen
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would be affected by
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845678#comment-17845678
]
Slawomir Jaranowski commented on MINVOKER-351:
--
[~mkjeldsen] thank it looks like we can simple use your example a next IT
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Mikkel Kjeldsen
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would be affected by it would already have unparseable JUnit reports.
> * I _believe_ that Java's {{j.u.r.Pattern}} can trivially express the
> complement of allowed characters but
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845665#comment-17845665
]
Mikkel Kjeldsen commented on MINVOKER-351:
--
[~sjaranowski], see [^minvoker-351.tar.gz] . {{verify}} successfully runs an
Invoker test and generates a JUnit test report. The test prints ASCII to
standard out; some of those characters are not allowed in XML (IIRC there are
more). {{site}} then fails to generate a Surefire report.
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Mikkel Kjeldsen
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: minvoker-351.tar.gz
>
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any
[jira] [Commented] (MINVOKER-351) Prevent XML-prohibited characters from entering JUnit report
[
https://issues.apache.org/jira/browse/MINVOKER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845549#comment-17845549
]
Slawomir Jaranowski commented on MINVOKER-351:
--
[~mkjeldsen] please provide a simple project which can reproduce it
> Prevent XML-prohibited characters from entering JUnit report
>
>
> Key: MINVOKER-351
> URL: https://issues.apache.org/jira/browse/MINVOKER-351
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Mikkel Kjeldsen
>Priority: Major
>
> Neither the Maven Invoker plugin's implementation of {{}}
> nor the underlying XML infrastructure directly protect against the presence
> of character literals prohibited by the XML specification, meaning such
> literals can appear in the JUnit report and render it unreadable. *I would
> appreciate if the Maven Invoker plugin could learn to strip prohibited
> literals to protect its users from creative plugins.* I argue that this is a
> safe and expected transformation that is not materially lossy.
>
> h2. Background
> MINVOKER-196 added the {{}} option [back in
> maven-invoker-plugin-3.2.1|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.2.1/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1878-L1946].
> As of [maven-invoker-plugin-3.6.0 the effective implementation of the JUnit
> report remains effectively
> unchanged|https://github.com/apache/maven-invoker-plugin/blob/maven-invoker-plugin-3.6.0/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L1695-L1754].
> The JUnit report includes a {{}} element ([example
> documentation|https://github.com/testmoapp/junitxml]) whose value Maven
> Invoker populates with the raw build log contents. I've observed that this
> value is XML-escaped, which I imagine is well understood in the
> implementation, although I can't immediately find documentation to support
> that.
> However, escaping notwithstanding, a number of character literals are
> outright prohibited by the XML specifications. These literals cannot be
> escaped, and their presence renders an XML document not well formed. The
> exact set of prohibited characters varies by XML version; the report produced
> by the Maven Invoker plugin is XML version 1.0. When the Maven Invoker plugin
> reads in the build log it does not strip these character literals and neither
> does the XML writer the Maven Invoker plugin relies on. Consequently, if a
> build log ends up including a prohibited character the resulting JUnit report
> will not be well formed.
> The set of prohibited characters is the complement of [the XML
> specification's definition of {{Char}}|https://www.w3.org/TR/xml/#NT-Char].
> h2. Example
> Among the literals prohibited by XML version 1.0 is {{^H}} (backspace). When
> [pitest runs via Maven|https://pitest.org/quickstart/maven/] it prints a
> spinner to standard out, and the implementation uses backspace to render the
> spinner in place. I have used the Maven Invoker plugin with
> {{}} to verify a pitest configuration, whereby I discovered
> this limitation.
> h2. Remediation
> h3. Blame plugins
> Perhaps pitest should not behave this way but we can't change pitest, and
> even if pitest could be changed that offers no protection against any other
> plugin, so blaming plugins is an ineffective course of action.
> h3. Work-arounds
> The user can manually clean the build log in-place via
> {{}}. This is technically fairly easy to do, and makes
> the transformation very explicit, but it requires considerable local work to
> address an issue many would find obscure and the transformation is
> permanently lossy unless the user also backs up the raw log to another file
> name.
> h3. Strip prohibited literals inside Maven Invoker plugin
> If the Maven Invoker plugin learns to strip offending character literals
> in-between reading the build log and writing to the {{}} value
> then {{}} will Just Work™, which I assert is what a user
> will typically expect. Although the {{}} value will no longer
> exactly match the build log contents, this lossy translation is acceptable:
> the prohibited characters are overwhelmingly unprintable to begin with and
> therefore cannot be meaningfully rendered in a static context, and the raw
> build log remains unchanged in the event that the user needs to investigate
> or assert against the raw output.
> This change would be backwards compatible, because any existing user that
> would be affected by it would already have unparseable JUnit reports.
> * I _believe_ that Java's {{j.u.r.Pattern}} can trivially express the
> complement of allowed characters but there may exist more efficient solutions.
> * Consider also applying this transformation to the 2
