[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327187#comment-327187 ] Uwe Schindler (ASF) commented on MJAVADOC-370: -- [~olamy]: For sure I can propose a fix to add charsets to Oracle's tool in the github project. But my main suggestion here is to *not use the original Oracle tool at all*, because the whole stuff it does can be done with a few lines of higher-level code in Maven already (using DirectoryScanner and plexus-utils search/replace in files). > 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 > > 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
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327190#comment-327190 ] Uwe Schindler (ASF) commented on MJAVADOC-370: -- bq. I agree that the Oracle tool is looking less and less useful as a means of patching the files; it should probably only be used in check mode (assuming that the encoding issue does not cause problems there as well). The check mode is just a grep with a little little bit more logic that can be done in one shell line :-) In my opinion, Oracle's code is buggy-to-hell? and is more a poorly implemented patch & grep tool. *Don't use it! Fix it by reimplementing with higher level tools from plexus-utils!* > 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 > > 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
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327193#comment-327193 ] Uwe Schindler (ASF) commented on MJAVADOC-370: -- No official Javadoc tool before the bugfix release has the url length bug. The bug was introduced by the first fixup tool and early openjdk commits (see commits on Oracle's HG). And its not a security relevant bug, it just breaks the javascript from working correctly. So they fix 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 >Assignee: Olivier Lamy >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
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327194#comment-327194 ] Uwe Schindler (ASF) commented on MJAVADOC-370: -- But I agree, you could aldo do the hotfix, if you like. But the original Oracle patch code does this only under special conditions: validURL(url) function found in code (so already a patched variant). On our LUCENE issue I am currently investigating what the fixup tool does with non-Oracle-JDK JDK's: IBM J9 and Oracle JRockit. If they both are also vulnerabe, the tool in Maven/Ant should also fix the bugs in them correctly. > 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 > > 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
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ 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 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
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ 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
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327201#comment-327201 ] Uwe Schindler (ASF) commented on MJAVADOC-370: -- To conclude: - I tested with JDK 1.5.0_22 -> patch applied correctly - I tested with JDK 1.6.0_32 -> patch applied correctly - I tested with JDK 1.7.0_21 -> patch applied correctly - I tested with JDK 1.7.0_25 -> no patching done at all (not vulnerable) - I tested with JDK 1.8.0-ea-b91 (still vulnerable build) -> patch applied correctly (tests still failed, but that's a preexisting JDK8 bug) > 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
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ 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 Slightly improved patch (removed the encoding null checks as FileUtils does it for us, i use the "official file name pattern" from the patcher now) > 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 > > > 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
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ 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 A new patch that uses the Javascript code as copied out of an index file as patched by Oracle's tool. The replacement code is in a resource now as plain text (US-ASCII encoded) and loaded before patching. > 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 > > > 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
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ 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
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327207#comment-327207 ] Uwe Schindler (ASF) edited comment on MJAVADOC-370 at 6/23/13 4:35 PM: --- I streamlined the patch a bit more and removed the separate class. The code patching the javadocs output is now in AbstractJavadocMojo, the patch data in a 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?). was (Author: thetaphi): 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
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327220#comment-327220 ] Uwe Schindler (ASF) commented on MJAVADOC-370: -- Hi, I just wanted to confirm that the auto-patching also works with IBM J9 6, IBM J9 7, and jRockit 6 (tested on Lucene's ANT task but the algorithm here is the same). Those JDKs produce identical javascript and are vulnerable like Oracle's original. Uwe > 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 > Fix For: 2.9.1 > > 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
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327226#comment-327226 ] Uwe Schindler (ASF) commented on MJAVADOC-370: -- FYI, for ANT users I filed a similar issue: https://issues.apache.org/bugzilla/show_bug.cgi?id=55132 > 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 > Fix For: 2.9.1 > > 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
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327696#comment-327696 ] Uwe Schindler (ASF) commented on MJAVADOC-370: -- Shouldn't the Apache Root POM not be updated ASAP to prevent any more security leaks? http://repo1.maven.org/maven2/org/apache/apache/13/apache-13.pom > 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 > Fix For: 2.9.1 > > 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
