Maven Javadoc Plugin
  1. Maven Javadoc Plugin
  2. MJAVADOC-370

Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.9.1
    • Labels:
      None

      Description

      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

        Activity

        sebbasf created issue -
        Hide
        Kristian Rosenvold added a comment -

        How do we know if this license is acceptable ?

        Show
        Kristian Rosenvold added a comment - How do we know if this license is acceptable ?
        Hide
        Sebb added a comment -

        The license says:

        We grant you a perpetual, nonexclusive, limited license to use, modify and
        distribute the Program in binary and/or source code form, only for the
        purpose of analyzing the directory structure of your computer system and
        updating Java API Documentation files. If you distribute the Program, in
        either or both binary or source form, including as modified by you, you
        shall include this License Agreement ("Agreement") with your distribution.

        Show
        Sebb added a comment - The license says: We grant you a perpetual, nonexclusive, limited license to use, modify and distribute the Program in binary and/or source code form, only for the purpose of analyzing the directory structure of your computer system and updating Java API Documentation files. If you distribute the Program, in either or both binary or source form, including as modified by you, you shall include this License Agreement ("Agreement") with your distribution.
        Hide
        Sebb added a comment -

        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.

        Show
        Sebb added a comment - 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.
        Hide
        Sebb added a comment -

        Another possibility might be to rely on a 3rd party plugin/library to actually run the Oracle fix code.

        I don't know if this is technically possible, but the idea would be to check if the user has installed the plugin, and if so, use it to provide the fix.

        Show
        Sebb added a comment - Another possibility might be to rely on a 3rd party plugin/library to actually run the Oracle fix code. I don't know if this is technically possible, but the idea would be to check if the user has installed the plugin, and if so, use it to provide the fix.
        Hide
        Oleg Kalnichevski added a comment -

        If JavadocUpdaterTool is loaded dynamically and used through reflection without directly importing its APIs this should address licensing concerns and leave it up to individuals to decide whether or not to accept the license.

        This fix is of critical importance to all projects that rely on Maven to build artifacts compatible with earlier versions of Java.

        Oleg

        Show
        Oleg Kalnichevski added a comment - If JavadocUpdaterTool is loaded dynamically and used through reflection without directly importing its APIs this should address licensing concerns and leave it up to individuals to decide whether or not to accept the license. This fix is of critical importance to all projects that rely on Maven to build artifacts compatible with earlier versions of Java. Oleg
        Hide
        Kristian Rosenvold added a comment -

        @Oleg And where would we get it from dynamically ?

        Show
        Kristian Rosenvold added a comment - @Oleg And where would we get it from dynamically ?
        Hide
        Oleg Kalnichevski added a comment -

        @Kristian
        Classpath would probably be a reasonable place to look.

        Oleg

        Show
        Oleg Kalnichevski added a comment - @Kristian Classpath would probably be a reasonable place to look. Oleg
        Hide
        Sebb added a comment -

        The 3rd party plugin details would need to be provided as a configuration item.

        The user would also need to add a dependency to the plugin so it gets added to the classpath.

        Alternatively, the configuration item could list the plugin GAV, in which case the user would have to ensure the plugin had already been downloaded. Obviously in that case the Javadoc plugin must not try and download the plugin.

        Show
        Sebb added a comment - The 3rd party plugin details would need to be provided as a configuration item. The user would also need to add a dependency to the plugin so it gets added to the classpath. Alternatively, the configuration item could list the plugin GAV, in which case the user would have to ensure the plugin had already been downloaded. Obviously in that case the Javadoc plugin must not try and download the plugin.
        Hide
        Oleg Kalnichevski added a comment -

        Why not make things simple and just leverage $MAVE_HOME/lib/ext? Isn't it what this directory is for in the first place?

        If Class.forName() produces a hit this most likely someone has gone to the trouble of downloading the damn tool from the Oracle web site and coping it to the ext location. If it is there, why not just use it?

        Oleg

        Show
        Oleg Kalnichevski added a comment - Why not make things simple and just leverage $MAVE_HOME/lib/ext? Isn't it what this directory is for in the first place? If Class.forName() produces a hit this most likely someone has gone to the trouble of downloading the damn tool from the Oracle web site and coping it to the ext location. If it is there, why not just use it? Oleg
        Hide
        Oleg Kalnichevski added a comment -

        > The user would also need to add a dependency to the plugin so it gets added to the classpath.

        @Sebastian
        Would not it imply making JavadocUpdaterTool available out of central repository as a versioned artifact?

        Oleg

        Show
        Oleg Kalnichevski added a comment - > The user would also need to add a dependency to the plugin so it gets added to the classpath. @Sebastian Would not it imply making JavadocUpdaterTool available out of central repository as a versioned artifact? Oleg
        Hide
        Sebb added a comment -

        That's another possibility, but I still think the Javadoc plugin needs to be told the class name to load.
        It seems wrong to fix the class name within the Javadoc plugin, so at least it should be possible to override the default.
        Ideally via a user property as well, so the user can add it to their settings.xml

        Unfortunately the Oracle tool has some bugs, so it would be useful to be able to use a 3rd party version of the tool which does not have those bugs. That is likely to have a different name.

        The user can still add the jar to lib/ext if they wish, or add it to the classpath via a dependency.

        Using lib/ext means no change to poms, but the jar will likel be lost if the Maven installation is updated.
        Using a dependency works with any Maven installation.

        Show
        Sebb added a comment - That's another possibility, but I still think the Javadoc plugin needs to be told the class name to load. It seems wrong to fix the class name within the Javadoc plugin, so at least it should be possible to override the default. Ideally via a user property as well, so the user can add it to their settings.xml Unfortunately the Oracle tool has some bugs, so it would be useful to be able to use a 3rd party version of the tool which does not have those bugs. That is likely to have a different name. The user can still add the jar to lib/ext if they wish, or add it to the classpath via a dependency. Using lib/ext means no change to poms, but the jar will likel be lost if the Maven installation is updated. Using a dependency works with any Maven installation.
        Hide
        Sebb added a comment -

        @Oleg
        There is already at least one 3rd party plugin; it is not available from a Maven repo yet as far as I know, but it can be downloaded and installed locally. That is not much more work than installing the Oracle tool, and is perhaps a more familiar procedure to Maven users.

        Show
        Sebb added a comment - @Oleg There is already at least one 3rd party plugin; it is not available from a Maven repo yet as far as I know, but it can be downloaded and installed locally. That is not much more work than installing the Oracle tool, and is perhaps a more familiar procedure to Maven users.
        Hide
        Olivier Lamy (*$^¨%`£) added a comment -

        The goal is to have the class JavadocFixTool available in Maven central via https://github.com/AdoptOpenJDK/JavadocUpdaterTool
        as it we can use it in a mojo.
        I already proposed a pull request.

        Show
        Olivier Lamy (*$^¨%`£) added a comment - The goal is to have the class JavadocFixTool available in Maven central via https://github.com/AdoptOpenJDK/JavadocUpdaterTool as it we can use it in a mojo. I already proposed a pull request.
        Olivier Lamy (*$^¨%`£) made changes -
        Field Original Value New Value
        Assignee Olivier Lamy [ olamy ]
        Hide
        Uwe Schindler added a comment - - edited

        Hi,
        I did some investigations on the tool as provided by Oracle:

        • It uses platform default encoding to patch the files. If you created your javadocs properly (as we do in lucene) by specifying -docencoding UTF-8, the patch tool corrupts them when patching (e.g. if you have special characters in your title tag which are e.g. not in your platform's encoding (all get replaced by ?). This happens when you regenerate e.g. on Windows with windows-1252 default charset. So the Oracle patch tool should at least be fixed to also allow to specify -docencoding
        • The patch tool is very simple at all, it just does two things: It looks for all files with the ANT/Maven-like pattern (case insensitive): **/index.htm*,**/toc.htm* that do not contain the validURL() javascript function. In ANT this can be achieved by a simple <fileset/> with a <restrict><not><contains .../></not></restrict> around. The patching at all is just a search/replace on all files found by this fileset, which can be realized on ANT using a <replace/> task. If you do all this in ANT, you can of course specify the correct encoding.

        I propose to not use Oracle's code at all (which uses plain JDK core libs, no helper tools for replacing available in plexus-utils) and implement it directly in the javadoc tool using DirectoryScanner and some simple file replace.

        For all that are interested, the ANT-based solution can be found on the Lucene project: LUCENE-5072

        Two notes:

        • the "quickfix" also done in the original Oracle tool can be left out for patching Maven Javadoc output. It is just there to fix patched javadocs that were done with an earlier buggy version of the fix tool. If you apply the patch (without the quickfix) on the output of the javadoc tool, you are fine. The quickfix is only useful for website administrators who patched before and introduced the javascript string length bug and want to fix their javadocs again.
        • The question is about the javascript code thats patched into the file. What is its license? It is definitely not the license of the updater tool! Oracle puts this javascript code in every index.html/toc.html file of any generated javado automatically. And these files are not haing any license header at all (what's the license of autogenerated code in produced javadoc HTML?). So I assume it is license-free (public domian).
        Show
        Uwe Schindler added a comment - - edited Hi, I did some investigations on the tool as provided by Oracle: It uses platform default encoding to patch the files. If you created your javadocs properly (as we do in lucene) by specifying -docencoding UTF-8 , the patch tool corrupts them when patching (e.g. if you have special characters in your title tag which are e.g. not in your platform's encoding (all get replaced by ?). This happens when you regenerate e.g. on Windows with windows-1252 default charset. So the Oracle patch tool should at least be fixed to also allow to specify -docencoding The patch tool is very simple at all, it just does two things: It looks for all files with the ANT/Maven-like pattern (case insensitive): **/index.htm*,**/toc.htm* that do not contain the validURL() javascript function. In ANT this can be achieved by a simple <fileset/> with a <restrict><not><contains .../></not></restrict> around. The patching at all is just a search/replace on all files found by this fileset, which can be realized on ANT using a <replace/> task. If you do all this in ANT, you can of course specify the correct encoding. I propose to not use Oracle's code at all (which uses plain JDK core libs, no helper tools for replacing available in plexus-utils) and implement it directly in the javadoc tool using DirectoryScanner and some simple file replace. For all that are interested, the ANT-based solution can be found on the Lucene project: LUCENE-5072 Two notes: the "quickfix" also done in the original Oracle tool can be left out for patching Maven Javadoc output. It is just there to fix patched javadocs that were done with an earlier buggy version of the fix tool. If you apply the patch (without the quickfix) on the output of the javadoc tool, you are fine. The quickfix is only useful for website administrators who patched before and introduced the javascript string length bug and want to fix their javadocs again. The question is about the javascript code thats patched into the file. What is its license? It is definitely not the license of the updater tool! Oracle puts this javascript code in every index.html/toc.html file of any generated javado automatically. And these files are not haing any license header at all (what's the license of autogenerated code in produced javadoc HTML?). So I assume it is license-free (public domian).
        Hide
        Olivier Lamy (*$^¨%`£) added a comment -

        @Uwe maybe you could propose a fix here: https://github.com/AdoptOpenJDK/JavadocUpdaterTool ?

        Show
        Olivier Lamy (*$^¨%`£) added a comment - @Uwe maybe you could propose a fix here: https://github.com/AdoptOpenJDK/JavadocUpdaterTool ?
        Hide
        Uwe Schindler added a comment -

        Olivier Lamy (*$^¨%`£): 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).

        Show
        Uwe Schindler added a comment - Olivier Lamy (*$^¨%`£) : 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).
        Hide
        Sebb added a comment -

        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).

        And even then of course, there may be false positives - it does not check much.
        But if it does report a vulnerability, that should of course be investigated.

        Show
        Sebb added a comment - 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). And even then of course, there may be false positives - it does not check much. But if it does report a vulnerability, that should of course be investigated.
        Hide
        Uwe Schindler added a comment -

        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!

        Show
        Uwe Schindler added a comment - 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!
        Hide
        Olivier Lamy (*$^¨%`£) added a comment -

        make sense

        Show
        Olivier Lamy (*$^¨%`£) added a comment - make sense
        Hide
        Sebb added a comment -

        The quickfix bug would still need to be considered for a goal that is used to check existing Javadoc as the old tool version may have been used to "fix" it.

        Was the quick fix (url length) bug definitely only introduced by the tool?
        Or was it copied from a javadoc version that was actually released?
        If the length bug was ever in javadoc output then the check for it should be included in the javadoc plugin goals too.

        Show
        Sebb added a comment - The quickfix bug would still need to be considered for a goal that is used to check existing Javadoc as the old tool version may have been used to "fix" it. Was the quick fix (url length) bug definitely only introduced by the tool? Or was it copied from a javadoc version that was actually released? If the length bug was ever in javadoc output then the check for it should be included in the javadoc plugin goals too.
        Hide
        Uwe Schindler added a comment -

        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.

        Show
        Uwe Schindler added a comment - 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.
        Hide
        Uwe Schindler added a comment -

        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.

        Show
        Uwe Schindler added a comment - 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.
        Hide
        Uwe Schindler added a comment - - edited

        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!

        Show
        Uwe Schindler added a comment - - edited 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!
        Uwe Schindler made changes -
        Attachment MJAVADOC-370.patch [ 63555 ]
        Hide
        Uwe Schindler added a comment -

        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)
        Show
        Uwe Schindler added a comment - 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)
        Hide
        Uwe Schindler added a comment -

        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)

        Show
        Uwe Schindler added a comment - 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)
        Uwe Schindler made changes -
        Attachment MJAVADOC-370.patch [ 63556 ]
        Hide
        Uwe Schindler added a comment -

        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.

        Show
        Uwe Schindler added a comment - 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.
        Uwe Schindler made changes -
        Attachment MJAVADOC-370.patch [ 63557 ]
        Hide
        Uwe Schindler added a comment - - edited

        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?).

        Show
        Uwe Schindler added a comment - - edited 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?).
        Uwe Schindler made changes -
        Attachment MJAVADOC-370.patch [ 63558 ]
        Hide
        Olivier Lamy (*$^¨%`£) added a comment -

        applied http://svn.apache.org/r1495902
        I will add a parameter to be able to disable the patch (on per default)

        Show
        Olivier Lamy (*$^¨%`£) added a comment - applied http://svn.apache.org/r1495902 I will add a parameter to be able to disable the patch (on per default)
        Hide
        Olivier Lamy (*$^¨%`£) added a comment -

        disable the patching configurable see http://svn.apache.org/r1495909

        Show
        Olivier Lamy (*$^¨%`£) added a comment - disable the patching configurable see http://svn.apache.org/r1495909
        Hide
        Sebb added a comment -

        The property name seems odd:

        @Parameter(defaultValue = "true", property = "maven.javadoc.securityfix.apply")
        private boolean applyJavadocSecurityFix = true;

        Why not use the same suffix as the configuration item? Less confusing.

        @Parameter(defaultValue = "true", property = "maven.javadoc.applyJavadocSecurityFix")
        private boolean applyJavadocSecurityFix = true;

        Show
        Sebb added a comment - The property name seems odd: @Parameter(defaultValue = "true", property = "maven.javadoc.securityfix.apply") private boolean applyJavadocSecurityFix = true; Why not use the same suffix as the configuration item? Less confusing. @Parameter(defaultValue = "true", property = "maven.javadoc.applyJavadocSecurityFix") private boolean applyJavadocSecurityFix = true;
        Hide
        Olivier Lamy (*$^¨%`£) added a comment -

        @sebb good remark. I changed it.
        Thanks!

        Show
        Olivier Lamy (*$^¨%`£) added a comment - @sebb good remark. I changed it. Thanks!
        Olivier Lamy (*$^¨%`£) made changes -
        Resolution Fixed [ 1 ]
        Fix Version/s 2.9.1 [ 18843 ]
        Status Open [ 1 ] Closed [ 6 ]
        Hide
        Uwe Schindler added a comment -

        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

        Show
        Uwe Schindler added a comment - 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
        Olivier Lamy (*$^¨%`£) made changes -
        Attachment MJAVADOC-370.patch [ 63555 ]
        Olivier Lamy (*$^¨%`£) made changes -
        Attachment MJAVADOC-370.patch [ 63556 ]
        Olivier Lamy (*$^¨%`£) made changes -
        Attachment MJAVADOC-370.patch [ 63557 ]
        Hide
        Uwe Schindler added a comment -

        FYI, for ANT users I filed a similar issue: https://issues.apache.org/bugzilla/show_bug.cgi?id=55132

        Show
        Uwe Schindler added a comment - FYI, for ANT users I filed a similar issue: https://issues.apache.org/bugzilla/show_bug.cgi?id=55132
        Hide
        Uwe Schindler added a comment -

        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

        Show
        Uwe Schindler added a comment - 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
        Hide
        Sebb added a comment -
        Show
        Sebb added a comment - +1 Created https://issues.apache.org/jira/browse/MPOM-46
        Mark Thomas made changes -
        Project Import Sun Apr 05 11:56:47 UTC 2015 [ 1428235007093 ]
        Mark Thomas made changes -
        Workflow jira [ 12722601 ] Default workflow, editable Closed status [ 12762328 ]
        Mark Thomas made changes -
        Project Import Mon Apr 06 00:11:46 UTC 2015 [ 1428279106587 ]
        Mark Thomas made changes -
        Workflow jira [ 12960092 ] Default workflow, editable Closed status [ 12996998 ]
        Mark Thomas made changes -
        Reporter SebbASF [ sebbasf ] Sebb [ sebb@apache.org ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Closed Closed
        4d 11h 14m 1 Olivier Lamy (*$^¨%`£) 24/Jun/13 05:50

          People

          • Assignee:
            Olivier Lamy (*$^¨%`£)
            Reporter:
            Sebb
          • Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development