On 19 June 2013 15:36, Mark Thomas <ma...@apache.org> wrote: > On 19/06/2013 15:12, sebb wrote: >> >> On 19 June 2013 14:12, Konstantin Kolinko <knst.koli...@gmail.com> wrote: >>> >>> 2013/6/19 sebb <seb...@gmail.com>: >>>> >>>> On 19 June 2013 13:12, sebb <seb...@gmail.com> wrote: >>>>> >>>>> On 19 June 2013 13:03, Nick Williams <nicho...@nicholaswilliams.net> >>>>> wrote: >>>>>> >>>>>> >>>>>> On Jun 19, 2013, at 3:15 AM, Mark Thomas 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. >>>>> >>>>> >>>>> I'd recommend running the fix tool after running javadoc; it's quick >>>>> and the license looks OK to include in an SVN build tools area. >>>>> >>>>> It's not just that you have to use Java 7, you have to use Java 7 u25 >>>>> or later. >>>>> Can that be detected reliably? >>>> >>>> >>>> Just to make it more fun, the javadoc tool does not display its >>>> version... >>>> >>> >>>> javadoc.exe -J-version >>> >>> >>> java version "1.7.0_21" >>> Java(TM) SE Runtime Environment (build 1.7.0_21-b11) >>> Java HotSpot(TM) Client VM (build 23.21-b01, mixed mode, sharing) >> >> >> Thanks; would not have thought of that. >> >> <aside> >> Should be OK unless javadoc.exe is somehow left over from an older >> installation. [Yes, it's rather unlikely] >> I just deleted my previous Java 7 installation so I cannot try it at >> present. >> I tried Javadoc.exe 6 and it does not work with Java 7 nor vice-versa, >> but might possibly work with the same version. >> I guess it depends on how compatible the dynamic libraries etc. are. >> </aside> >> >> Anyway, back to the problem: >> >> I've been thinking how to run the Javadoc fix tool, in Maven and Ant >> builds >> Also where to store (source and) binary version of the tool. >> Seems wasteful if every project has their own version in SVN. >> >> It occurred to me that it might be useful to create a Maven plugin as >> well as a jar (hopefully the same one) that can be run from the >> command-line. >> I can create some code in Commons Sandbox to do this. >> Anyone could then check it out of SVN and build locally (would need >> Maven) and use for trialling fixes to Ant/Maven build scripts. >> >> If the approach works, then it should be fairly quick to get the >> plugin voted on and released in Commons, and it would then be usable >> by all. >> >> Does that sound like something Tomcat could use? > > > Nope. Tomcat builds with Ant, not Maven.
I know, that is why the jar would have a main manifest entry as well. > The Oracle provided JAR is fine. Sort of - it does not work properly on Windows (fails to delete the old copy of the file) . Now Eclipse tells me it fails to close some resources. It's unlikely that the resource leaks would cause failures except in pathological cases, but still. > The JAR is so small (5k) that multiple copies in svn really isn't an issue. I know. It was more that having compiled versions of source in SVN is not a good precedent. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
