[
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327185#comment-327185
]
Uwe Schindler edited comment on MJAVADOC-370 at 6/23/13 5:34 AM:
-----------------------------------------------------------------
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|https://issues.apache.org/jira/browse/LUCENE-5072?focusedCommentId=13691419&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13691419]
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).
was (Author: thetaphi):
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 pathcing (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|https://issues.apache.org/jira/browse/LUCENE-5072?focusedCommentId=13691419&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13691419]
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).
> 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
