[
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327199#comment-327199
]
Uwe Schindler (ASF) edited comment on MJAVADOC-370 at 6/23/13 10:19 AM:
------------------------------------------------------------------------
Attached is my quick fix thats directly included into the javadoc maven Mojo.
The abstract base class calls an additional patcher class directly after
invoking Javadoc shell command. The patching code is in a separate class at the
moment. It has almost nothing to do anymore with Oracle's original fix. It uses
FileUtils and StringUtils and DirectoryScanner from Plexus to do all patching,
respecting the output charset of the javadoc ran before.
The only part that was taken from Oracle's file was the "patch data" (the
script data to replace). As this script data is in every published Javadoc file
I assume it is public domain. At least the license of the Javascript code is
*not* the same like the Oracle patch tool, because it is string data only.
I was not able to add a test, but from what I see after running tests:
- If I run (mvn test) using a vulnerable JDK, the files are patched correctly
(see test output directory) and the tests display a corresponding log line
- If I run with JDK 1.7.0u25, the patches are not applied and no additional log
lines appear when running tests.
I hope this patch may function as a start of integrating this into Maven's main
javadoc plugin. I am no Maven developer (I love Ant too much), but hopefully
the code is fine!
was (Author: thetaphi):
Attached is my quick fix thats directly included into the javadoc maven
Mojo.
The abstract base class calls an additional patcher class directly after
invoking Javadoc shell command. The patching code is in a separate class at the
moment. It has almost nothing to do anymore with Oracle's original fix. It uses
FileUtils and StringUtils and DirectoryScanner from Plexus to do all patching,
respecting the output charset of the javadoc ran before.
The only part that was taken from Oracle's file was the "patch data" (the
javadoc to replace). As this javadoc is in every published Javadoc file I
assume it is public domain. At least the license of the Javascript code is
*not* the same like the Oracle patch tool, because it is string data only.
I was not able to add a test, but from what I see after running tests:
- If I run (mvn test) using a vulnerable JDK, the files are patched correctly
(see test output directory) and the tests display a corresponding log line
- If I run with JDK 1.7.0u25, the patches are not applied and no additional log
lines appear when running tests.
I hope this patch may function as a start of integrating this into Maven's main
javadoc plugin. I am no Maven developer (I love Ant too much), but hopefully
the code is fine!
> Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
> ---------------------------------------------------------
>
> Key: MJAVADOC-370
> URL: https://jira.codehaus.org/browse/MJAVADOC-370
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Improvement
> Reporter: SebbASF
> Assignee: Olivier Lamy
> Priority: Blocker
> Attachments: MJAVADOC-370.patch
>
>
> As per the Maven dev list:
> I expect you have all see the news about the Javadoc javascript bug.
> It's going to take a long time for everyone to update their Java
> installations to Java 1.7 u25. Likewise for builds that need to use
> other Java versions, tweaking poms so Java 7 is used for Javadocs
> whilst still maintaining compatibility is a non-trivial task.
> Is there any interest in releasing a "quick-fix" version of the
> javadoc plugin that automatically runs the tool after Javadoc
> completes?
> The fix code is in Java, and can easily be directly called from the
> plugin (no need to start a new process).
> The license looks friendly so long as the code is only used for
> Javadoc fixups, and changes are allowed, which is just as well -
> There are a couple of bugs in the tool as currently released.
> It does not close all the resources; and failure to close the input
> file means it cannot delete the original input file on Windows; that
> needs to be fixed as it would not make sense to keep the old faulty
> file (even if it is now called index.html.orig).
> I can provide details of the fixes, but a decent IDE will probably
> warn about them anyway.
> It would be a great service to the Java community if this could be
> fast-tracked.
> [1]
> http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html
> [2]http://www.kb.cert.org/vuls/id/225657
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
