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. > >> I will file an issue about this two, but I wanted to go ahead and >> make the list aware. > > > Thanks, > > Mark > > > >> Nick >> >> [1] >> >> http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html >> >> > [2] http://www.kb.cert.org/vuls/id/225657 >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
