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. It looks like it was written by a novice Java programmer. 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). -chris
signature.asc
Description: OpenPGP digital signature
