[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327087#comment-327087 ]
SebbASF commented on MJAVADOC-370: ---------------------------------- See also https://issues.apache.org/jira/browse/LEGAL-171. In the meantime, would it be possible to release a version of the Javadoc plugin that creates an error if the generated Javadoc is vulnerable? One way to do this would be to check the javadoc tool version - if it is 1.7.0_25 or later, then it's OK. This might have some false negatives as early javadocs did not generate scripts. I assume that should be fairly easy to do - and would offer some protection. If the license issues are sorted out, then the new code could be enhanced to do the fix. > 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 > Priority: Blocker > > 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