subject:"\[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
 ]

Olivier Lamy closed MJAVADOC-370.
-

   Resolution: Fixed
Fix Version/s: 2.9.1

 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-tabpanelfocusedCommentId=327219#comment-327219
]

Olivier Lamy commented on MJAVADOC-370:
---

@sebb good remark. I changed it.
Thanks!

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

2013-06-24 Thread Uwe Schindler (ASF) (JIRA)


[ 
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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:all-tabpanel
 ]

Olivier Lamy updated MJAVADOC-370:
--

Attachment: (was: MJAVADOC-370.patch)

 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:all-tabpanel
 ]

Olivier Lamy updated MJAVADOC-370:
--

Attachment: (was: MJAVADOC-370.patch)

 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:all-tabpanel
 ]

Olivier Lamy updated MJAVADOC-370:
--

Attachment: (was: MJAVADOC-370.patch)

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

2013-06-24 Thread Uwe Schindler (ASF) (JIRA)


[ 
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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])

2013-06-23 Thread Uwe Schindler (JIRA)


[ 
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 
{{restrictnotcontains ...//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=13691419page=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 
{{restrictnotcontains ...//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=13691419page=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

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

2013-06-23 Thread Uwe Schindler (JIRA)

[
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327185#comment-327185
]

Uwe Schindler commented on MJAVADOC-370:

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
{{restrictnotcontains ...//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=13691419page=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

[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-tabpanelfocusedCommentId=327186#comment-327186
 ] 

Olivier Lamy commented on MJAVADOC-370:
---

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

 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-tabpanelfocusedCommentId=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])

2013-06-23 Thread SebbASF (JIRA)


[ 
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327189#comment-327189
 ] 

SebbASF commented on MJAVADOC-370:
--

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.

 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-tabpanelfocusedCommentId=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

[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-tabpanelfocusedCommentId=327191#comment-327191
 ] 

Olivier Lamy commented on MJAVADOC-370:
---

make sense

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

2013-06-23 Thread SebbASF (JIRA)


[ 
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327192#comment-327192
 ] 

SebbASF commented on MJAVADOC-370:
--

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.

 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-tabpanelfocusedCommentId=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

[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-tabpanelfocusedCommentId=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

[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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])
-

[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-tabpanelfocusedCommentId=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.

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.

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

[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-tabpanelfocusedCommentId=327210#comment-327210
 ] 

Olivier Lamy commented on MJAVADOC-370:
---

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


 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-tabpanelfocusedCommentId=327211#comment-327211
 ] 

Olivier Lamy commented on MJAVADOC-370:
---

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

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

2013-06-22 Thread Olivier Lamy (JIRA)


[ 
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327159#comment-327159
 ] 

Olivier Lamy commented on MJAVADOC-370:
---

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.

 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

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

2013-06-22 Thread Olivier Lamy (JIRA)


 [ 
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy reassigned MJAVADOC-370:
-

Assignee: Olivier Lamy

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

2013-06-21 Thread Oleg Kalnichevski (JIRA)

[
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327120#comment-327120
]

Oleg Kalnichevski commented on MJAVADOC-370:

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

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

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

2013-06-21 Thread Oleg Kalnichevski (JIRA)


[ 
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327122#comment-327122
 ] 

Oleg Kalnichevski commented on MJAVADOC-370:


 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

 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

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

2013-06-21 Thread SebbASF (JIRA)

[
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327125#comment-327125
]

SebbASF commented on MJAVADOC-370:
--

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.

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

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

2013-06-21 Thread SebbASF (JIRA)


[ 
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327127#comment-327127
 ] 

SebbASF commented on MJAVADOC-370:
--

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

 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

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

2013-06-20 Thread Kristian Rosenvold (JIRA)


[ 
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327041#comment-327041
 ] 

Kristian Rosenvold commented on MJAVADOC-370:
-

How do we know if this license is acceptable ?

 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

[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-tabpanelfocusedCommentId=327047#comment-327047
 ] 

SebbASF commented on MJAVADOC-370:
--

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.


 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

[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-tabpanelfocusedCommentId=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

[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-tabpanelfocusedCommentId=327088#comment-327088
 ] 

SebbASF commented on MJAVADOC-370:
--

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.

 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

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

2013-06-20 Thread Oleg Kalnichevski (JIRA)


[ 
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327092#comment-327092
 ] 

Oleg Kalnichevski commented on MJAVADOC-370:


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 

 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

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

2013-06-20 Thread Kristian Rosenvold (JIRA)


[ 
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327093#comment-327093
 ] 

Kristian Rosenvold commented on MJAVADOC-370:
-

@Oleg And where would we get it from dynamically ?


 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

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

2013-06-20 Thread Oleg Kalnichevski (JIRA)


[ 
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327094#comment-327094
 ] 

Oleg Kalnichevski commented on MJAVADOC-370:


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

Oleg

 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

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