[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691285#comment-13691285
]
Steve Rowe edited comment on LUCENE-5072 at 6/22/13 11:34 PM:
--------------------------------------------------------------
bq. About License: The Javscript code in this patch is also autogenerated by
Oracle's own tool, so its license should not matter (because Oracle's tool
prints it in every file we distribute - we just emulate what Oracle's tool
does).
+1, I agree with this.
I patched trunk ran {{ant generate-maven-artifacts}} using Oracle 1.7.0_21 JDK
on OS X - I saw lines like the following in Ant's output, so the macro is doing
it's job:
{noformat}
[patch-javadoc] Replaced 1 occurrences in 1 files.
{noformat}
I then unpacked all the {{*-javadoc.jar}} files under {{dist/}}, then ran the
following, which printed nothing, which I judge as success:
{noformat}
grep -L 'function validURL(url) {' $(grep -l 'function loadFrames() {' $(find .
-name index.htm -o -name index.html -o -name toc.htm -o -name toc.html))
{noformat}
Then I ran {{ant clean documentation}} and the following script also printed
nothing, again success:
{noformat}
grep -L 'function validURL(url) {' $(grep -l 'function loadFrames() {' $(find
{lucene,solr}/build/docs -name index.html -o -name index.htm -o -name toc.htm
-o -name toc.html))
{noformat}
was (Author: steve_rowe):
bq. About License: The Javscript code in this patch is also autogenerated
by Oracle's own tool, so its license should not matter (because Oracle's tool
prints it in every file we distribute - we just emulate what Oracle's tool
does).
+1, I agree with this.
I patched trunk ran {{ant generate-maven-artifacts}} using Oracle 1.7.0_21 JDK
on OS X - I saw lines like the following in Ant's output, so the macro is doing
it's job:
{noformat}
{noformat}
I then unpacked all the {{*-javadoc.jar}} files under {{dist/}}, then ran the
following, which printed nothing, which I judge as success:
{noformat}
grep -L 'function validURL(url) {' $(grep -l 'function loadFrames() {' $(find .
-name index.htm -o -name index.html -o -name toc.htm -o -name toc.html))
{noformat}
Then I ran {{ant clean documentation}} and the following script also printed
nothing, again success:
{noformat}
grep -L 'function validURL(url) {' $(grep -l 'function loadFrames() {' $(find
{lucene,solr}/build/docs -name index.html -o -name index.htm -o -name toc.htm
-o -name toc.html))
{noformat}
> Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with
> Java 6 (and Java 7 prior u25)
> ---------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-5072
> URL: https://issues.apache.org/jira/browse/LUCENE-5072
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
> Affects Versions: 4.3.1
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-5072.patch, LUCENE-5072.patch
>
>
> The Apache Infra / Security team posted to all committers:
> {quote}
> Hi All,
> Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
> generated by Java 5, Java 6 and Java 7 before update 22.
> [...]
> Please take the necessary steps to fix any currently published Javadoc and to
> ensure that any future Javadoc published by your project does not contain the
> vulnerability. The announcement by Oracle includes a link to a tool that can
> be used to fix Javadoc without regeneration.
> The infrastructure team is investigating options for preventing the
> publication of vulnerable Javadoc.
> The issue is public and may be discussed freely on your project's dev list.
> Thanks,
> Mark (ASF Infra)
> {quote}
> I fixed all published Javadocs on http://lucene.apache.org (for all historic
> releases where we have public available Javadocs on the web page).
> The mail also notes that we should not publish javadocs with this javadocs
> problem in the future. Unfortunately the release manager has to use the
> latest Java 7u25 version (released 2 days) ago. This would be fine for Lucene
> trunk (which is Java 7 only).
> But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7
> (to build the official release) because the javadocs would contain e.g.
> AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
> for web pages).
> We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
> built with Java 5 (3.x) or Java 6 (4.x).
> Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its
> impossible to do a release.
> But Oracle publishes the binary and source code of a "fix tool", that can be
> run on top of a tree of HTML files, patching all broken files (and only
> those). You can run it theoretically on the root folder of your harddisk - I
> did this on the whole lucene.apache.org web site.
> Robert Muir and I were looking for a IVY-compatible solution (the original
> Oracle tool cannot be automatically downloaded by IVY, as Oracle's website
> sets cookies and requests license confirmations). We found the following
> GITHUB project by olamy/karianna:
> https://github.com/AdoptOpenJDK/JavadocUpdaterTool
> As soon as they release the JAR file officially on Maven, we can download it
> with IVY and use it. This is a Maven Plugin, but it still contains the
> original source code of Oracle's tool, so we can execute it as ANT task after
> loading the JAR with IVY's coordinates: {{<java fork="false" class="..."/>}}
> In the GITHUB project description they note that you need JDK7 to use the
> tool, but this is no longer true, the -source/-target is Java 5 now, so we
> can run it easily.
> I will add the required tasks in common-build.xml's javadoc macro so it
> post-processes all javadocs and patches vulnerable files. If you build
> javadocs with a recent JDK, it would do nothing.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
