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. [If you checkout [1] and "mvn install" the plugin, you should be able to run it locally] [1] https://svn.apache.org/repos/asf/commons/proper/commons-javadocfix-plugin/trunk/ > It looks like it was written by a novice Java programmer. Who either did not use an IDE or ignored the warnings. > The good news is that the license allows you (we) to modify the source > code and redistribute it. So, we can even publish a fixed version if we > choose to (rather than merely keeping it for ourselves). That's how I read it too. > -chris > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
