[
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler (ASF) updated MJAVADOC-370:
-----------------------------------------
Attachment: MJAVADOC-370.patch
I streamlined the patch a bit more and removed the separate class.
The code pathing the javadocs output is now in AbstractJavadocMojo, the patch
data ina resource file (encoded as US-ASCII). This is now easy to understand.
Currently there is no Mojo @Parameter to disable the patching, maybe we should
add it.
I will report back once I tested with non-Oracle JDK if the patch is really
safe for all types of Javadocs (JRockit, IBM J9). If not we should add some
detection for Orcale/Sun/OpenJDK's JDKs and only patch Javadocs generated by
their doclet (or only patch the default doclet?).
> 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, MJAVADOC-370.patch,
> MJAVADOC-370.patch, 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
