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. The Oracle provided JAR is fine.
The JAR is so small (5k) that multiple copies in svn really isn't an
issue. There are individual projects doing far worse.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
