On 20 June 2013 16:33, Christopher Schultz <ch...@christopherschultz.net> wrote: > Sebb, > > On 6/20/13 9:31 AM, sebb wrote: >> On 20 June 2013 14:16, Christopher Schultz <ch...@christopherschultz.net> >> wrote: >>> Sebb, >>> >>> On 6/19/13 4:26 AM, sebb wrote: >>>> On 19 June 2013 09:15, Mark Thomas <ma...@apache.org> wrote: >>>>> On 19/06/2013 00:42, Nick Williams wrote: >>>>>> >>>>>> Oracle has announced a Javadoc vulnerability (CVE-2013-1571 [1], >>>>>> VU#225657 [2]) whereby Javadoc generated with Java 5, Java 6, or Java >>>>>> 7 < 7u25 is vulnerable to a frame injection attack. Oracle has >>>>>> provided a repair-in-place tool for Javadoc that cannot be easily >>>>>> regenerated, but is urging developers to regenerate whatever Javadoc >>>>>> they can using Java 7u25. For all practical purses, the vulnerability >>>>>> really only applies to publicly-hosted Javadoc, so the Javadoc in our >>>>>> existing Maven artifacts, downloads, and archived downloads really >>>>>> doesn't have to be worried about (not that we could do anything about >>>>>> it). My thoughts on this: >>>>>> >>>>>> 1) We should apply the repair-in-place tool ASAP to the Javadoc on >>>>>> the website for Tomcat 6 and Tomcat 7. >>>>> >>>>> >>>>> And Tomcat 5 and earlier. The javadoc for those isn't linked but remains >>>>> available. >>>>> >>>>> I'll get on to this now. >>>>> >>>>> >>>>>> 2) Future Tomcat 6 and 7 Javadoc should be generated with 7u25 or >>>>>> better. >>>>> >>>>> >>>>> Hmm. That will need some thought as the build needs to be run with the >>>>> minimum Java version required for that major version. Maybe we can just >>>>> run >>>>> the Javadoc part with a different JDK. Either that, or run the fix tool >>>>> over >>>>> the result. This needs some investigation. >>>>> >>>>> >>>>>> There will be no fix for Java 5 or 6. Thankfully, generating >>>>>> Javadoc using a different JDK than you used to compile is quite easy >>>>>> in both Maven and Ant. In fact, I personally prefer it that way, >>>>>> because the Javadoc is much more visually attractive in Java 7. >>>>> >>>>> >>>>> Hopefully it will be as simple as you suggest. >>>>> >>>> >>>> I found for JMeter that the only file that needed fixing was the >>>> top-level index.html. >>>> If always true that reduces what needs to be checked-out/put back. >>>> >>>> There's also a bug in the quick-fix tool - it fails to delete the >>>> renamed original file (on Windows, which locks files from delete) >>>> because it fails to call fis.close() first. >>>> [The code does not check that the delete is successful either.] >>>> >>>> Should be easily possible to run the (fixed) tool on locally generated >>>> javadoc before committing in future. >>> >>> Wow, the code for that quick-fix tool really is awful. If run in >>> recursuve-mode, it will leave every file that matches the "file list" >>> (index.html, etc.) open until the finalizers run (hah). There are also >>> swallowed exceptions, no finally blocks, etc. >> >> I've made some fixes (resource closures); these are at: >> >> https://svn.apache.org/repos/asf/commons/proper/commons-javadocfix-plugin/trunk/src/main/java/org/apache/commons/plugins/javadocfix/JavadocFixTool.java >> >> Comments welcome if you spot any more. > > I think you want to do a lot of the close() operations in finally > blocks, in case exceptions occur.
Agreed, but it was simpler to just fix the main-line code. At least now the resources are closed if exceptions don't occur - which was not the case previously. > While it probably won't allow the > program to function any better (that is, the old file need not be > deleted unless it is successfully-processed), it will reduce the number > of file handles kept open by the process. Just noticed that the original file is renamed too early. If the code generates an IOE before the temporary file is completed and the rename attempted, the user is not informed that the file has been renamed. > -chris --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
