[jira] (MNG-5486) hiding transfer logs
[
https://jira.codehaus.org/browse/MNG-5486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jigar Joshi updated MNG-5486:
-
Attachment: maven_qtl.patch
> hiding transfer logs
>
>
> Key: MNG-5486
> URL: https://jira.codehaus.org/browse/MNG-5486
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line, Embedding, Logging, Performance
>Affects Versions: 3.0.5, 3.1.0
>Reporter: Jigar Joshi
>Priority: Minor
> Attachments: maven_qtl.patch, maven_qtl.patch, maven_qtl.patch
>
>
> Maven {{ConsoleMavenTransferListener}} adds too much verbose logs, Which is
> not required in all the cases and most of the time people uses it (
> {{ConsoleMavenTransferListener}} by default)
> It causes little overhead,
> For example: in CI build it adds those logs which is not required all the
> time, also (in my case) it triggers the build of a very large maven project
> tree at each 10 min adding lots of logs on disk
> Also there are other people who wants this feature as well
> http://maven.40175.n5.nabble.com/m2-Turning-off-download-log-messages-td46662.html
> http://stackoverflow.com/questions/3409918/maven-how-can-i-stop-the-deploy-plugin-from-logging-upload-progress
> I know there is a {{-q}} but which gets very quiet, so it would be nice if we
> are able to just quiet transfer logs
> I modified maven source to hide those log based on the parameter and using it
> successfully
> I have attached the patch here which was applied against 3.1-SNAPSHOT
> specifically at revision : 1495788
> https://svn.apache.org/repos/asf/maven/maven-3/trunk
> added new parameter
> {{-qtl}}
> to make quiet transfer log
> If I overlooked anything and did over engineering please let me know,
> Otherwise I would love to see this option in next release
> Thanks!
> Jigar
--
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] (MNG-5486) hiding transfer logs
[
https://jira.codehaus.org/browse/MNG-5486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327179#comment-327179
]
Jigar Joshi edited comment on MNG-5486 at 6/23/13 2:23 AM:
---
http://jira.codehaus.org/secure/attachment/63554/maven_qtl.patch is little
cleaner than first one
was (Author: jigar.joshi):
http://jira.codehaus.org/secure/attachment/63552/maven_qtl.patch is little
cleaner than first one
> hiding transfer logs
>
>
> Key: MNG-5486
> URL: https://jira.codehaus.org/browse/MNG-5486
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line, Embedding, Logging, Performance
>Affects Versions: 3.0.5, 3.1.0
>Reporter: Jigar Joshi
>Priority: Minor
> Attachments: maven_qtl.patch, maven_qtl.patch, maven_qtl.patch
>
>
> Maven {{ConsoleMavenTransferListener}} adds too much verbose logs, Which is
> not required in all the cases and most of the time people uses it (
> {{ConsoleMavenTransferListener}} by default)
> It causes little overhead,
> For example: in CI build it adds those logs which is not required all the
> time, also (in my case) it triggers the build of a very large maven project
> tree at each 10 min adding lots of logs on disk
> Also there are other people who wants this feature as well
> http://maven.40175.n5.nabble.com/m2-Turning-off-download-log-messages-td46662.html
> http://stackoverflow.com/questions/3409918/maven-how-can-i-stop-the-deploy-plugin-from-logging-upload-progress
> I know there is a {{-q}} but which gets very quiet, so it would be nice if we
> are able to just quiet transfer logs
> I modified maven source to hide those log based on the parameter and using it
> successfully
> I have attached the patch here which was applied against 3.1-SNAPSHOT
> specifically at revision : 1495788
> https://svn.apache.org/repos/asf/maven/maven-3/trunk
> added new parameter
> {{-qtl}}
> to make quiet transfer log
> If I overlooked anything and did over engineering please let me know,
> Otherwise I would love to see this option in next release
> Thanks!
> Jigar
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 {{}} with a
{{}} 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 {{}} task. If you do all this in ANT, you can
of course specify the correct encoding.
I propose to not use Oracle's code at all (which uses plain JDK core libs, no
helper tools for replacing available in plexus-utils) and implement it directly
in the javadoc tool using DirectoryScanner and some simple file replace.
For all that are interested, the ANT-based solution can be found on the Lucene
project:
[LUCENE-5072|https://issues.apache.org/jira/browse/LUCENE-5072?focusedCommentId=13691419&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13691419]
Two notes:
- the "quickfix" also done in the original Oracle tool can be left out for
patching Maven Javadoc output. It is just there to fix patched javadocs that
were done with an earlier buggy version of the fix tool. If you apply the patch
(without the quickfix) on the output of the javadoc tool, you are fine. The
quickfix is only useful for website administrators who patched before and
introduced the javascript string length bug and want to fix their javadocs
again.
- The question is about the *javascript code* thats patched into the file. What
is its license? It is definitely not the license of the updater tool! Oracle
puts this javascript code in every index.html/toc.html file of any generated
javado automatically. And these files are not haing any license header at all
(what's the license of autogenerated code in produced javadoc HTML?). So I
assume it is license-free (public domian).
was (Author: thetaphi):
Hi,
I did some investigations on the tool as provided by Oracle:
- It uses platform default encoding to patch the files. If you created your
javadocs properly (as we do in lucene) by specifying {{-docencoding UTF-8}},
the patch tool corrupts them when pathcing (e.g. if you have special characters
in your title tag which are e.g. not in your platform's encoding (all get
replaced by ?). This happens when you regenerate e.g. on Windows with
windows-1252 default charset. So the Oracle patch tool should at least be fixed
to also allow to specify {{-docencoding}}
- The patch tool is very simple at all, it just does two things: It looks for
all files with the ANT/Maven-like pattern (case insensitive):
{{\*\*/index.htm*,\*\*/toc.htm*}} that do not contain the validURL() javascript
function. In ANT this can be achieved by a simple {{}} with a
{{}} 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 {{}} task. If you do all this in ANT, you can
of course specify the correct encoding.
I propose to not use Oracle's code at all (which uses plain JDK core libs, no
helper tools for replacing available in plexus-utils) and implement it directly
in the javadoc tool using DirectoryScanner and some simple file replace.
For all that are interested, the ANT-based solution can be found on the Lucene
project:
[LUCENE-5072|https://issues.apache.org/jira/browse/LUCENE-5072?focusedCommentId=13691419&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13691419]
Two notes:
- the "quickfix" also done in the original Oracle tool can be left out for
patching Maven Javadoc output. It is just there to fix patched javadocs that
were done with an earlier buggy version of the fix tool. If you apply the patch
(without the quickfix) on the output of the javadoc tool, you are fine. The
quickfix is only useful for website administrators who patched before and
introduced the javascript string length bug and want to fix their javadocs
again.
- The question is about the *javascript code* thats patched into the file. What
is its licen
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[
https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 {{}} with a
{{}} 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 {{}} task. If you do all this in ANT, you can
of course specify the correct encoding.
I propose to not use Oracle's code at all (which uses plain JDK core libs, no
helper tools for replacing available in plexus-utils) and implement it directly
in the javadoc tool using DirectoryScanner and some simple file replace.
For all that are interested, the ANT-based solution can be found on the Lucene
project:
[LUCENE-5072|https://issues.apache.org/jira/browse/LUCENE-5072?focusedCommentId=13691419&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13691419]
Two notes:
- the "quickfix" also done in the original Oracle tool can be left out for
patching Maven Javadoc output. It is just there to fix patched javadocs that
were done with an earlier buggy version of the fix tool. If you apply the patch
(without the quickfix) on the output of the javadoc tool, you are fine. The
quickfix is only useful for website administrators who patched before and
introduced the javascript string length bug and want to fix their javadocs
again.
- The question is about the *javascript code* thats patched into the file. What
is its license? It is definitely not the license of the updater tool! Oracle
puts this javascript code in every index.html/toc.html file of any generated
javado automatically. And these files are not haing any license header at all
(what's the license of autogenerated code in produced javadoc HTML?). So I
assume it is license-free (public domian).
> Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
> -
>
> Key: MJAVADOC-370
> URL: https://jira.codehaus.org/browse/MJAVADOC-370
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Improvement
>Reporter: SebbASF
>Assignee: Olivier Lamy
>Priority: Blocker
>
> As per the Maven dev list:
> I expect you have all see the news about the Javadoc javascript bug.
> It's going to take a long time for everyone to update their Java
> installations to Java 1.7 u25. Likewise for builds that need to use
> other Java versions, tweaking poms so Java 7 is used for Javadocs
> whilst still maintaining compatibility is a non-trivial task.
> Is there any interest in releasing a "quick-fix" version of the
> javadoc plugin that automatically runs the tool after Javadoc
> completes?
> The fix code is in Java, and can easily be directly called from the
> plugin (no need to start a new process).
> The license looks friendly so long as the code is only used for
> Javadoc fixups, and changes are allowed, which is just as well -
> There are a couple of bugs in the tool as currently released.
> It does not close all the resources; and failure to close the input
> file means it cannot delete the original input file on Windows; that
> needs to be fixed as it would not make sense to keep the old faulty
> file (even if it is now called index.html.orig).
> I can provide details of the fixes, but a decent IDE will probably
> warn about them anyway.
> It would be a great service to the Java community if this could be
> fast-tracked.
> [1]
> http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html
> [2]http://www.kb.cert.org/vuls/id/225657
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=327187#comment-327187 ] Uwe Schindler (ASF) commented on MJAVADOC-370: -- [~olamy]: For sure I can propose a fix to add charsets to Oracle's tool in the github project. But my main suggestion here is to *not use the original Oracle tool at all*, because the whole stuff it does can be done with a few lines of higher-level code in Maven already (using DirectoryScanner and plexus-utils search/replace in files). > Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2]) > - > > Key: MJAVADOC-370 > URL: https://jira.codehaus.org/browse/MJAVADOC-370 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Reporter: SebbASF >Assignee: Olivier Lamy >Priority: Blocker > > As per the Maven dev list: > I expect you have all see the news about the Javadoc javascript bug. > It's going to take a long time for everyone to update their Java > installations to Java 1.7 u25. Likewise for builds that need to use > other Java versions, tweaking poms so Java 7 is used for Javadocs > whilst still maintaining compatibility is a non-trivial task. > Is there any interest in releasing a "quick-fix" version of the > javadoc plugin that automatically runs the tool after Javadoc > completes? > The fix code is in Java, and can easily be directly called from the > plugin (no need to start a new process). > The license looks friendly so long as the code is only used for > Javadoc fixups, and changes are allowed, which is just as well - > There are a couple of bugs in the tool as currently released. > It does not close all the resources; and failure to close the input > file means it cannot delete the original input file on Windows; that > needs to be fixed as it would not make sense to keep the old faulty > file (even if it is now called index.html.orig). > I can provide details of the fixes, but a decent IDE will probably > warn about them anyway. > It would be a great service to the Java community if this could be > fast-tracked. > [1] > http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html > [2]http://www.kb.cert.org/vuls/id/225657 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=327190#comment-327190 ] Uwe Schindler (ASF) commented on MJAVADOC-370: -- bq. I agree that the Oracle tool is looking less and less useful as a means of patching the files; it should probably only be used in check mode (assuming that the encoding issue does not cause problems there as well). The check mode is just a grep with a little little bit more logic that can be done in one shell line :-) In my opinion, Oracle's code is buggy-to-hell? and is more a poorly implemented patch & grep tool. *Don't use it! Fix it by reimplementing with higher level tools from plexus-utils!* > Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2]) > - > > Key: MJAVADOC-370 > URL: https://jira.codehaus.org/browse/MJAVADOC-370 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Reporter: SebbASF >Assignee: Olivier Lamy >Priority: Blocker > > As per the Maven dev list: > I expect you have all see the news about the Javadoc javascript bug. > It's going to take a long time for everyone to update their Java > installations to Java 1.7 u25. Likewise for builds that need to use > other Java versions, tweaking poms so Java 7 is used for Javadocs > whilst still maintaining compatibility is a non-trivial task. > Is there any interest in releasing a "quick-fix" version of the > javadoc plugin that automatically runs the tool after Javadoc > completes? > The fix code is in Java, and can easily be directly called from the > plugin (no need to start a new process). > The license looks friendly so long as the code is only used for > Javadoc fixups, and changes are allowed, which is just as well - > There are a couple of bugs in the tool as currently released. > It does not close all the resources; and failure to close the input > file means it cannot delete the original input file on Windows; that > needs to be fixed as it would not make sense to keep the old faulty > file (even if it is now called index.html.orig). > I can provide details of the fixes, but a decent IDE will probably > warn about them anyway. > It would be a great service to the Java community if this could be > fast-tracked. > [1] > http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html > [2]http://www.kb.cert.org/vuls/id/225657 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=327193#comment-327193 ] Uwe Schindler (ASF) commented on MJAVADOC-370: -- No official Javadoc tool before the bugfix release has the url length bug. The bug was introduced by the first fixup tool and early openjdk commits (see commits on Oracle's HG). And its not a security relevant bug, it just breaks the javascript from working correctly. So they fix the fix. > Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2]) > - > > Key: MJAVADOC-370 > URL: https://jira.codehaus.org/browse/MJAVADOC-370 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Reporter: SebbASF >Assignee: Olivier Lamy >Priority: Blocker > > As per the Maven dev list: > I expect you have all see the news about the Javadoc javascript bug. > It's going to take a long time for everyone to update their Java > installations to Java 1.7 u25. Likewise for builds that need to use > other Java versions, tweaking poms so Java 7 is used for Javadocs > whilst still maintaining compatibility is a non-trivial task. > Is there any interest in releasing a "quick-fix" version of the > javadoc plugin that automatically runs the tool after Javadoc > completes? > The fix code is in Java, and can easily be directly called from the > plugin (no need to start a new process). > The license looks friendly so long as the code is only used for > Javadoc fixups, and changes are allowed, which is just as well - > There are a couple of bugs in the tool as currently released. > It does not close all the resources; and failure to close the input > file means it cannot delete the original input file on Windows; that > needs to be fixed as it would not make sense to keep the old faulty > file (even if it is now called index.html.orig). > I can provide details of the fixes, but a decent IDE will probably > warn about them anyway. > It would be a great service to the Java community if this could be > fast-tracked. > [1] > http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html > [2]http://www.kb.cert.org/vuls/id/225657 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327194#comment-327194 ] Uwe Schindler (ASF) commented on MJAVADOC-370: -- But I agree, you could aldo do the hotfix, if you like. But the original Oracle patch code does this only under special conditions: validURL(url) function found in code (so already a patched variant). On our LUCENE issue I am currently investigating what the fixup tool does with non-Oracle-JDK JDK's: IBM J9 and Oracle JRockit. If they both are also vulnerabe, the tool in Maven/Ant should also fix the bugs in them correctly. > Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2]) > - > > Key: MJAVADOC-370 > URL: https://jira.codehaus.org/browse/MJAVADOC-370 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Reporter: SebbASF >Assignee: Olivier Lamy >Priority: Blocker > > As per the Maven dev list: > I expect you have all see the news about the Javadoc javascript bug. > It's going to take a long time for everyone to update their Java > installations to Java 1.7 u25. Likewise for builds that need to use > other Java versions, tweaking poms so Java 7 is used for Javadocs > whilst still maintaining compatibility is a non-trivial task. > Is there any interest in releasing a "quick-fix" version of the > javadoc plugin that automatically runs the tool after Javadoc > completes? > The fix code is in Java, and can easily be directly called from the > plugin (no need to start a new process). > The license looks friendly so long as the code is only used for > Javadoc fixups, and changes are allowed, which is just as well - > There are a couple of bugs in the tool as currently released. > It does not close all the resources; and failure to close the input > file means it cannot delete the original input file on Windows; that > needs to be fixed as it would not make sense to keep the old faulty > file (even if it is now called index.html.orig). > I can provide details of the fixes, but a decent IDE will probably > warn about them anyway. > It would be a great service to the Java community if this could be > fast-tracked. > [1] > http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html > [2]http://www.kb.cert.org/vuls/id/225657 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler (ASF) updated MJAVADOC-370: - Attachment: MJAVADOC-370.patch Attached is my quick fix thats directly included into the javadoc maven Mojo. The abstract base class calls an additional patcher class directly after invoking Javadoc shell command. The patching code is in a separate class at the moment. It has almost nothing to do anymore with Oracle's original fix. It uses FileUtils and StringUtils and DirectoryScanner from Plexus to do all patching, respecting the output charset of the javadoc ran before. The only part that was taken from Oracle's file was the "patch data" (the javadoc to replace). As this javadoc is in every published Javadoc file I assume it is public domain. At least the license of the Javascript code is *not* the same like the Oracle patch tool, because it is string data only. I was not able to add a test, but from what I see after running tests: - If I run (mvn test) using a vulnerable JDK, the files are patched correctly (see test output directory) and the tests display a corresponding log line - If I run with JDK 1.7.0u25, the patches are not applied and no additional log lines appear when running tests. I hope this patch may function as a start of integrating this into Maven's main javadoc plugin. I am no Maven developer (I love Ant too much), but hopefully the code is fine! > Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2]) > - > > Key: MJAVADOC-370 > URL: https://jira.codehaus.org/browse/MJAVADOC-370 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Reporter: SebbASF >Assignee: Olivier Lamy >Priority: Blocker > Attachments: MJAVADOC-370.patch > > > As per the Maven dev list: > I expect you have all see the news about the Javadoc javascript bug. > It's going to take a long time for everyone to update their Java > installations to Java 1.7 u25. Likewise for builds that need to use > other Java versions, tweaking poms so Java 7 is used for Javadocs > whilst still maintaining compatibility is a non-trivial task. > Is there any interest in releasing a "quick-fix" version of the > javadoc plugin that automatically runs the tool after Javadoc > completes? > The fix code is in Java, and can easily be directly called from the > plugin (no need to start a new process). > The license looks friendly so long as the code is only used for > Javadoc fixups, and changes are allowed, which is just as well - > There are a couple of bugs in the tool as currently released. > It does not close all the resources; and failure to close the input > file means it cannot delete the original input file on Windows; that > needs to be fixed as it would not make sense to keep the old faulty > file (even if it is now called index.html.orig). > I can provide details of the fixes, but a decent IDE will probably > warn about them anyway. > It would be a great service to the Java community if this could be > fast-tracked. > [1] > http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html > [2]http://www.kb.cert.org/vuls/id/225657 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327199#comment-327199 ] Uwe Schindler (ASF) edited comment on MJAVADOC-370 at 6/23/13 10:19 AM: Attached is my quick fix thats directly included into the javadoc maven Mojo. The abstract base class calls an additional patcher class directly after invoking Javadoc shell command. The patching code is in a separate class at the moment. It has almost nothing to do anymore with Oracle's original fix. It uses FileUtils and StringUtils and DirectoryScanner from Plexus to do all patching, respecting the output charset of the javadoc ran before. The only part that was taken from Oracle's file was the "patch data" (the script data to replace). As this script data is in every published Javadoc file I assume it is public domain. At least the license of the Javascript code is *not* the same like the Oracle patch tool, because it is string data only. I was not able to add a test, but from what I see after running tests: - If I run (mvn test) using a vulnerable JDK, the files are patched correctly (see test output directory) and the tests display a corresponding log line - If I run with JDK 1.7.0u25, the patches are not applied and no additional log lines appear when running tests. I hope this patch may function as a start of integrating this into Maven's main javadoc plugin. I am no Maven developer (I love Ant too much), but hopefully the code is fine! was (Author: thetaphi): Attached is my quick fix thats directly included into the javadoc maven Mojo. The abstract base class calls an additional patcher class directly after invoking Javadoc shell command. The patching code is in a separate class at the moment. It has almost nothing to do anymore with Oracle's original fix. It uses FileUtils and StringUtils and DirectoryScanner from Plexus to do all patching, respecting the output charset of the javadoc ran before. The only part that was taken from Oracle's file was the "patch data" (the javadoc to replace). As this javadoc is in every published Javadoc file I assume it is public domain. At least the license of the Javascript code is *not* the same like the Oracle patch tool, because it is string data only. I was not able to add a test, but from what I see after running tests: - If I run (mvn test) using a vulnerable JDK, the files are patched correctly (see test output directory) and the tests display a corresponding log line - If I run with JDK 1.7.0u25, the patches are not applied and no additional log lines appear when running tests. I hope this patch may function as a start of integrating this into Maven's main javadoc plugin. I am no Maven developer (I love Ant too much), but hopefully the code is fine! > Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2]) > - > > Key: MJAVADOC-370 > URL: https://jira.codehaus.org/browse/MJAVADOC-370 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Reporter: SebbASF >Assignee: Olivier Lamy >Priority: Blocker > Attachments: MJAVADOC-370.patch > > > As per the Maven dev list: > I expect you have all see the news about the Javadoc javascript bug. > It's going to take a long time for everyone to update their Java > installations to Java 1.7 u25. Likewise for builds that need to use > other Java versions, tweaking poms so Java 7 is used for Javadocs > whilst still maintaining compatibility is a non-trivial task. > Is there any interest in releasing a "quick-fix" version of the > javadoc plugin that automatically runs the tool after Javadoc > completes? > The fix code is in Java, and can easily be directly called from the > plugin (no need to start a new process). > The license looks friendly so long as the code is only used for > Javadoc fixups, and changes are allowed, which is just as well - > There are a couple of bugs in the tool as currently released. > It does not close all the resources; and failure to close the input > file means it cannot delete the original input file on Windows; that > needs to be fixed as it would not make sense to keep the old faulty > file (even if it is now called index.html.orig). > I can provide details of the fixes, but a decent IDE will probably > warn about them anyway. > It would be a great service to the Java community if this could be > fast-tracked. > [1] > http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html > [2]http://www.kb.cert.org/vuls/id/225657 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327201#comment-327201 ] Uwe Schindler (ASF) commented on MJAVADOC-370: -- To conclude: - I tested with JDK 1.5.0_22 -> patch applied correctly - I tested with JDK 1.6.0_32 -> patch applied correctly - I tested with JDK 1.7.0_21 -> patch applied correctly - I tested with JDK 1.7.0_25 -> no patching done at all (not vulnerable) - I tested with JDK 1.8.0-ea-b91 (still vulnerable build) -> patch applied correctly (tests still failed, but that's a preexisting JDK8 bug) > Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2]) > - > > Key: MJAVADOC-370 > URL: https://jira.codehaus.org/browse/MJAVADOC-370 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Reporter: SebbASF >Assignee: Olivier Lamy >Priority: Blocker > Attachments: MJAVADOC-370.patch > > > As per the Maven dev list: > I expect you have all see the news about the Javadoc javascript bug. > It's going to take a long time for everyone to update their Java > installations to Java 1.7 u25. Likewise for builds that need to use > other Java versions, tweaking poms so Java 7 is used for Javadocs > whilst still maintaining compatibility is a non-trivial task. > Is there any interest in releasing a "quick-fix" version of the > javadoc plugin that automatically runs the tool after Javadoc > completes? > The fix code is in Java, and can easily be directly called from the > plugin (no need to start a new process). > The license looks friendly so long as the code is only used for > Javadoc fixups, and changes are allowed, which is just as well - > There are a couple of bugs in the tool as currently released. > It does not close all the resources; and failure to close the input > file means it cannot delete the original input file on Windows; that > needs to be fixed as it would not make sense to keep the old faulty > file (even if it is now called index.html.orig). > I can provide details of the fixes, but a decent IDE will probably > warn about them anyway. > It would be a great service to the Java community if this could be > fast-tracked. > [1] > http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html > [2]http://www.kb.cert.org/vuls/id/225657 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler (ASF) updated MJAVADOC-370: - Attachment: MJAVADOC-370.patch Slightly improved patch (removed the encoding null checks as FileUtils does it for us, i use the "official file name pattern" from the patcher now) > Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2]) > - > > Key: MJAVADOC-370 > URL: https://jira.codehaus.org/browse/MJAVADOC-370 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Reporter: SebbASF >Assignee: Olivier Lamy >Priority: Blocker > Attachments: MJAVADOC-370.patch, MJAVADOC-370.patch > > > As per the Maven dev list: > I expect you have all see the news about the Javadoc javascript bug. > It's going to take a long time for everyone to update their Java > installations to Java 1.7 u25. Likewise for builds that need to use > other Java versions, tweaking poms so Java 7 is used for Javadocs > whilst still maintaining compatibility is a non-trivial task. > Is there any interest in releasing a "quick-fix" version of the > javadoc plugin that automatically runs the tool after Javadoc > completes? > The fix code is in Java, and can easily be directly called from the > plugin (no need to start a new process). > The license looks friendly so long as the code is only used for > Javadoc fixups, and changes are allowed, which is just as well - > There are a couple of bugs in the tool as currently released. > It does not close all the resources; and failure to close the input > file means it cannot delete the original input file on Windows; that > needs to be fixed as it would not make sense to keep the old faulty > file (even if it is now called index.html.orig). > I can provide details of the fixes, but a decent IDE will probably > warn about them anyway. > It would be a great service to the Java community if this could be > fast-tracked. > [1] > http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html > [2]http://www.kb.cert.org/vuls/id/225657 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler (ASF) updated MJAVADOC-370: - Attachment: MJAVADOC-370.patch A new patch that uses the Javascript code as copied out of an index file as patched by Oracle's tool. The replacement code is in a resource now as plain text (US-ASCII encoded) and loaded before patching. > Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2]) > - > > Key: MJAVADOC-370 > URL: https://jira.codehaus.org/browse/MJAVADOC-370 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Reporter: SebbASF >Assignee: Olivier Lamy >Priority: Blocker > Attachments: MJAVADOC-370.patch, MJAVADOC-370.patch, > MJAVADOC-370.patch > > > As per the Maven dev list: > I expect you have all see the news about the Javadoc javascript bug. > It's going to take a long time for everyone to update their Java > installations to Java 1.7 u25. Likewise for builds that need to use > other Java versions, tweaking poms so Java 7 is used for Javadocs > whilst still maintaining compatibility is a non-trivial task. > Is there any interest in releasing a "quick-fix" version of the > javadoc plugin that automatically runs the tool after Javadoc > completes? > The fix code is in Java, and can easily be directly called from the > plugin (no need to start a new process). > The license looks friendly so long as the code is only used for > Javadoc fixups, and changes are allowed, which is just as well - > There are a couple of bugs in the tool as currently released. > It does not close all the resources; and failure to close the input > file means it cannot delete the original input file on Windows; that > needs to be fixed as it would not make sense to keep the old faulty > file (even if it is now called index.html.orig). > I can provide details of the fixes, but a decent IDE will probably > warn about them anyway. > It would be a great service to the Java community if this could be > fast-tracked. > [1] > http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html > [2]http://www.kb.cert.org/vuls/id/225657 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler (ASF) updated MJAVADOC-370: - Attachment: MJAVADOC-370.patch I streamlined the patch a bit more and removed the separate class. The code pathing the javadocs output is now in AbstractJavadocMojo, the patch data ina resource file (encoded as US-ASCII). This is now easy to understand. Currently there is no Mojo @Parameter to disable the patching, maybe we should add it. I will report back once I tested with non-Oracle JDK if the patch is really safe for all types of Javadocs (JRockit, IBM J9). If not we should add some detection for Orcale/Sun/OpenJDK's JDKs and only patch Javadocs generated by their doclet (or only patch the default doclet?). > Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2]) > - > > Key: MJAVADOC-370 > URL: https://jira.codehaus.org/browse/MJAVADOC-370 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Reporter: SebbASF >Assignee: Olivier Lamy >Priority: Blocker > Attachments: MJAVADOC-370.patch, MJAVADOC-370.patch, > MJAVADOC-370.patch, MJAVADOC-370.patch > > > As per the Maven dev list: > I expect you have all see the news about the Javadoc javascript bug. > It's going to take a long time for everyone to update their Java > installations to Java 1.7 u25. Likewise for builds that need to use > other Java versions, tweaking poms so Java 7 is used for Javadocs > whilst still maintaining compatibility is a non-trivial task. > Is there any interest in releasing a "quick-fix" version of the > javadoc plugin that automatically runs the tool after Javadoc > completes? > The fix code is in Java, and can easily be directly called from the > plugin (no need to start a new process). > The license looks friendly so long as the code is only used for > Javadoc fixups, and changes are allowed, which is just as well - > There are a couple of bugs in the tool as currently released. > It does not close all the resources; and failure to close the input > file means it cannot delete the original input file on Windows; that > needs to be fixed as it would not make sense to keep the old faulty > file (even if it is now called index.html.orig). > I can provide details of the fixes, but a decent IDE will probably > warn about them anyway. > It would be a great service to the Java community if this could be > fast-tracked. > [1] > http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html > [2]http://www.kb.cert.org/vuls/id/225657 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327207#comment-327207 ] Uwe Schindler (ASF) edited comment on MJAVADOC-370 at 6/23/13 4:35 PM: --- I streamlined the patch a bit more and removed the separate class. The code patching the javadocs output is now in AbstractJavadocMojo, the patch data in a resource file (encoded as US-ASCII). This is now easy to understand. Currently there is no Mojo @Parameter to disable the patching, maybe we should add it. I will report back once I tested with non-Oracle JDK if the patch is really safe for all types of Javadocs (JRockit, IBM J9). If not we should add some detection for Orcale/Sun/OpenJDK's JDKs and only patch Javadocs generated by their doclet (or only patch the default doclet?). was (Author: thetaphi): I streamlined the patch a bit more and removed the separate class. The code pathing the javadocs output is now in AbstractJavadocMojo, the patch data ina resource file (encoded as US-ASCII). This is now easy to understand. Currently there is no Mojo @Parameter to disable the patching, maybe we should add it. I will report back once I tested with non-Oracle JDK if the patch is really safe for all types of Javadocs (JRockit, IBM J9). If not we should add some detection for Orcale/Sun/OpenJDK's JDKs and only patch Javadocs generated by their doclet (or only patch the default doclet?). > Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2]) > - > > Key: MJAVADOC-370 > URL: https://jira.codehaus.org/browse/MJAVADOC-370 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Reporter: SebbASF >Assignee: Olivier Lamy >Priority: Blocker > Attachments: MJAVADOC-370.patch, MJAVADOC-370.patch, > MJAVADOC-370.patch, MJAVADOC-370.patch > > > As per the Maven dev list: > I expect you have all see the news about the Javadoc javascript bug. > It's going to take a long time for everyone to update their Java > installations to Java 1.7 u25. Likewise for builds that need to use > other Java versions, tweaking poms so Java 7 is used for Javadocs > whilst still maintaining compatibility is a non-trivial task. > Is there any interest in releasing a "quick-fix" version of the > javadoc plugin that automatically runs the tool after Javadoc > completes? > The fix code is in Java, and can easily be directly called from the > plugin (no need to start a new process). > The license looks friendly so long as the code is only used for > Javadoc fixups, and changes are allowed, which is just as well - > There are a couple of bugs in the tool as currently released. > It does not close all the resources; and failure to close the input > file means it cannot delete the original input file on Windows; that > needs to be fixed as it would not make sense to keep the old faulty > file (even if it is now called index.html.orig). > I can provide details of the fixes, but a decent IDE will probably > warn about them anyway. > It would be a great service to the Java community if this could be > fast-tracked. > [1] > http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html > [2]http://www.kb.cert.org/vuls/id/225657 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGELOG-135) Support Short Revision Numbers for Git
Steve Kallestad created MCHANGELOG-135: -- Summary: Support Short Revision Numbers for Git Key: MCHANGELOG-135 URL: https://jira.codehaus.org/browse/MCHANGELOG-135 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Affects Versions: 2.2 Environment: n/a Reporter: Steve Kallestad Priority: Minor In change log reports generated for git, it uses the long commit string. Example: path/to/changed/file v 57a61dd4d58a5882800b78d6b5694c4121550633 This makes the change log report distracting to read. Instead short numbers should be leveraged. Reference for generating and leveraging these numbers is here: http://git-scm.com/book/ch6-1.html -- 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] (MCHANGELOG-136) displayFileDetailUrl generates Errors when running mvn site
Steve Kallestad created MCHANGELOG-136:
--
Summary: displayFileDetailUrl generates Errors when running mvn
site
Key: MCHANGELOG-136
URL: https://jira.codehaus.org/browse/MCHANGELOG-136
Project: Maven 2.x Changelog Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: Windows 7
Reporter: Steve Kallestad
When you include a configuration setting that includes the %FILE% token
anywhere in the url:
http://myscmwebenterface/?f=%FILE%
A series of errors are generated when running mvn site. These errors are not
generated when running mvn changelog:file-activity
[INFO] Generating "File Activity" report--- maven-changelog-plugin:2.2
[INFO] Using existing changelog.xml...
[ERROR] Illegal group reference
[ERROR] Illegal group reference
[ERROR] Illegal group reference
[ERROR] Illegal group reference
[ERROR] Illegal group reference
[ERROR] No group 1
[ERROR] No group 2
[ERROR] No group 3
[ERROR] No group 4
[ERROR] No group 5
[ERROR] No group 6
[ERROR] No group 7
[ERROR] Illegal group reference
[ERROR] No group 1
[ERROR] No group 1
[ERROR] Illegal group reference
[ERROR] Illegal group reference
[ERROR] Illegal group reference
[ERROR] Illegal group reference
[ERROR] Illegal group reference
[ERROR] Illegal group reference
[ERROR] Illegal group reference
[ERROR] Illegal group reference
[ERROR] Illegal group reference
[ERROR] Illegal group reference
[ERROR] No group 1
[ERROR] No group 1
[ERROR] No group 1
[ERROR] No group 1
[ERROR] No group 1
[ERROR] No group 1
[ERROR] No group 1
[ERROR] No group 1
[ERROR] No group 1
[ERROR] No group 1
[ERROR] No group 1
[ERROR] No group 1
[ERROR] No group 1
[ERROR] No group 2
[ERROR] No group 2
[ERROR] No group 2
Running with -X shows that these errors point to ChangeLogReport.java line 1501
- relevant snippet here:
1497 // Use the given URL to create links to the files
1498
1499 if ( linkFile.indexOf( FILE_TOKEN ) > 0 )
1500 {
1501 linkFile = linkFile.replaceAll( FILE_TOKEN, name );
1502 }
1503 else
--
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] (MCHANGELOG-136) displayFileDetailUrl generates Errors when running mvn site
[
https://jira.codehaus.org/browse/MCHANGELOG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327208#comment-327208
]
Steve Kallestad commented on MCHANGELOG-136:
The resulting report seems to generate fine. The reported error set is
extraordinarily large.
A workaround for removing the errors exists if the file location can be moved
to the end of the URL.
instead of:
http://myscmwebenterface/?f=%FILE%
use:
http://myscmwebenterface/?f=
And the file location will be automatically appended to the end of the URL.
> displayFileDetailUrl generates Errors when running mvn site
> ---
>
> Key: MCHANGELOG-136
> URL: https://jira.codehaus.org/browse/MCHANGELOG-136
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows 7
>Reporter: Steve Kallestad
>
> When you include a configuration setting that includes the %FILE% token
> anywhere in the url:
> http://myscmwebenterface/?f=%FILE%
> A series of errors are generated when running mvn site. These errors are not
> generated when running mvn changelog:file-activity
> [INFO] Generating "File Activity" report--- maven-changelog-plugin:2.2
> [INFO] Using existing changelog.xml...
> [ERROR] Illegal group reference
> [ERROR] Illegal group reference
> [ERROR] Illegal group reference
> [ERROR] Illegal group reference
> [ERROR] Illegal group reference
> [ERROR] No group 1
> [ERROR] No group 2
> [ERROR] No group 3
> [ERROR] No group 4
> [ERROR] No group 5
> [ERROR] No group 6
> [ERROR] No group 7
> [ERROR] Illegal group reference
> [ERROR] No group 1
> [ERROR] No group 1
> [ERROR] Illegal group reference
> [ERROR] Illegal group reference
> [ERROR] Illegal group reference
> [ERROR] Illegal group reference
> [ERROR] Illegal group reference
> [ERROR] Illegal group reference
> [ERROR] Illegal group reference
> [ERROR] Illegal group reference
> [ERROR] Illegal group reference
> [ERROR] Illegal group reference
> [ERROR] No group 1
> [ERROR] No group 1
> [ERROR] No group 1
> [ERROR] No group 1
> [ERROR] No group 1
> [ERROR] No group 1
> [ERROR] No group 1
> [ERROR] No group 1
> [ERROR] No group 1
> [ERROR] No group 1
> [ERROR] No group 1
> [ERROR] No group 1
> [ERROR] No group 1
> [ERROR] No group 2
> [ERROR] No group 2
> [ERROR] No group 2
> Running with -X shows that these errors point to ChangeLogReport.java line
> 1501 - relevant snippet here:
> 1497 // Use the given URL to create links to the files
> 1498
> 1499 if ( linkFile.indexOf( FILE_TOKEN ) > 0 )
> 1500 {
> 1501 linkFile = linkFile.replaceAll( FILE_TOKEN, name );
> 1502 }
> 1503 else
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-370) Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2])
[ https://jira.codehaus.org/browse/MJAVADOC-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] (MASSEMBLY-657) "jar" assembly format produces unexpected MANIFEST files and ignores "index" attribute with different archive settings
Oleksii Batiuk created MASSEMBLY-657:
Summary: "jar" assembly format produces unexpected MANIFEST files
and ignores "index" attribute with different archive settings
Key: MASSEMBLY-657
URL: https://jira.codehaus.org/browse/MASSEMBLY-657
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Components: manifest
Affects Versions: 2.4
Reporter: Oleksii Batiuk
Attachments: manifest-test-0.1-project.zip
Basically, the problem is that assembly plugin generates unexpected MANIFEST.MF
file and _ignores_ "index" attributes when using "jar" format.
*Assumption*
Expected result is based on assumption that plugin should produce the same
result as default jar plugin does when using the same archive settings (they
both backed by the maven archiver). Attached archive contains test project that
generates three jars using the "maven-jar-plugin" and three other jars using
the "maven-assembly-plugin". Both plugins has the same archive settings.
*Test Data*
_Basic assembly plugin configuration:_
{code:xml}
org.apache.maven.plugins
maven-assembly-plugin
2.4
false
false
jar-with-dependencies
jar
false
true
...
{code}
{{src/main/assembly/META-INF/MANIFEST.MF:}}
{quote}
Manifest-Version: 1.0
DisplayName: Test Display Name
{quote}
*Test #1*
Execution that generates jar using default archiver MANIFEST file:
{code:xml}
assembly-with-default-manifest
package
single
${project.build.finalName}-assembly-default-manifest
{code}
_Expected result:_
INDEX.LIST file is present and contains:
{quote}JarIndex-Version: 1.0
manifest-test-0.1-assembly-default-manifest.jar
ru
ru/javatalks
ru/javatalks/tests
{quote}
MANIFEST.MF file is present and contains:
{quote}Manifest-Version: 1.0
Built-By: gesser
Build-Jdk: 1.6.0_45
Created-By: Apache Maven 3.0.5
Archiver-Version: Plexus Archiver
{quote}
_Actual Result:_
{color:red}INDEX.LIST file is missing.{color}
{color:green}MANIFEST.MF file exists and contains expected entries.{color}
*Test #2*
Execution that generates jar using custom MANIFEST file:
{code:xml}
assembly-with-custom-manifest
package
single
${project.build.finalName}-assembly-custom-manifest
src/main/assembly/META-INF/MANIFEST.MF
{code}
_Expected Result:_
INDEX.LIST file is present and contains:
{quote}JarIndex-Version: 1.0
manifest-test-0.1-assembly-custom-manifest.jar
ru
ru/javatalks
ru/javatalks/tests
{quote}
MANIFEST.MF file is present and contains:
{quote}Manifest-Version: 1.0
Built-By: gesser
Build-Jdk: 1.6.0_45
Created-By: Apache Maven 3.0.5
DisplayName: Test Display Name
Archiver-Version: Plexus Archiver
{quote}
_Actual Result:_
{color:red}INDEX.LIST file is missing.{color}
{color:red}MANIFEST.MF file exists, but contains unexpected entries:{color}
{quote}
Manifest-Version: 1.0
Created-By: 20.45-b01 (Sun Microsystems Inc.)
DisplayName: Test Display Name
Archiver-Version: Plexus Archiver
{quote}
*Test #3*
Execution that generates jar using custom MANIFEST file plus custom entries:
{code:xml}
assembly-with-custom-manifest-and-entries
package
single
${project.build.finalName}-assembly-custom-manifest-and-entries
src/main/assembly/META-INF/MANIFEST.MF
${maven.build.timestamp}
${project.version}
{code}
_Expected Result:_
INDEX.LIST file is present and contains:
{quote}JarIndex-Version: 1.0
manifest-test-0.1-assembly-custom-manifest-and-entries.jar
ru
ru/javatalks
ru/javatalks/tests
{quote}
MANIFEST.MF file is present and contains:
{quote}Manifest-Version: 1.0
Built-By: gesser
Build-Jdk: 1.6.0_45
Created-By: Apache Maven 3.0.5
Built-date: 20130623-2318
DisplayName: Test Display Name
Version: 0.1
Archiver-Version: Plexus Archiver
{quote}
_Actual Result:_
{color:red}INDEX.LIST file is missing.{color}
{color:red}MANIFEST.MF file exists, but contains unexpected entries:{color}
{quote}
Manifest-Version: 1.0
Created-By: 20.45-b01 (Sun Microsystems Inc.)
DisplayName: Test Display Name
Archiver-Version: Plexus Archiver
{quote}
*Additional information:*
Maven version: 3.0.5
Java version: 1.6.0_45
--
This message is automatically generated by JIRA.
If
[jira] (MSHARED-287) Add ability to generate basic manifest file without any default entries, generated by Maven Archiver
Oleksii Batiuk created MSHARED-287: -- Summary: Add ability to generate basic manifest file without any default entries, generated by Maven Archiver Key: MSHARED-287 URL: https://jira.codehaus.org/browse/MSHARED-287 Project: Maven Shared Components Issue Type: Improvement Components: maven-archiver Affects Versions: maven-archiver-2.5 Reporter: Oleksii Batiuk It is impossible to generate basic manifest file without *default* entries generated by Maven Archiver (such as: "Archiver-Version, "Build-Jdk", etc.) Simple manifest described in java tutorial and JAR file specification: http://docs.oracle.com/javase/tutorial/deployment/jar/defman.html, http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#JAR_Manifest -- 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
