-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cris,
On 10/17/18 12:28, Berneburg, Cris J. - US wrote: > Thanks Mark > > mt> The argument for a JRE vs a JDK is that the JDK includes mt> a > compiler. The only reason Tomcat can run on a JRE and mt> still > support JSPs (which require compilation) is that mt> Tomcat > includes a Java compiler. I don't think the mt> security argument > holds much water. > > I had not thought of that, and you're right (literally technically > speaking). > > RAMBLE: However, if I try to look at it from a point of view of a > large bureaucracy, of which I am largely ignorant, I would not be > surprised if there is a policy against dev kits and IDE's on > production servers for security sake. Tomcat (whisper: with > built-in compiler) is approved, but is the JDK allowed? Guess I > can ask. Yeah, it's potentially a "distinction without a > difference". Well, unless there are other tools in the JDK that > can pose security risks in addition to the Java compiler. Hard and fast rule: no compilers. Well, except for EJC, Perl, Python, PHP, *sh, and a host of other things capable of running code. It's a checkbox security "feature" that is all of meaningless, ineffective, and inconvenient. These days, most servers have all the code you'd already ever need to "compile" and run an exploit even if there were no compiler there. All you need is a nice, vulnerable pre-existing binary. https://crypto.stanford.edu/~blynn/rop/ > mt> OpenJDK is very close to the Oracle JDK these days. I mt> > regularly run Tomcat's unit tests with the latest OpenJDK mt> and > have yet to find an issue that is OpenJDK specific. mt> mt> Tomcat > runs happily (and is supported) on a JRE. mt> mt> If the JRE has > passed the Java TCK then Tomcat should run mt> on it. I don't think > there is an official Tomcat position mt> but my expectation is if a > Tomcat bug (as opposed to a mt> Java bug) appears when running on > any Java implementation mt> that has passed the TCK then the Tomcat > team would treat mt> that as a Tomcat bug and fix it. > > All good to know. > > cjb> I am imagining spending all my time being taken up by cjb> > Java upgrades with subsequent builds, regression testing, cjb> red > tape, and deployments > > mt> I'd plan to stick to the LTS releases. > > Meh, not my call. Whatever the Powers That Be decide for the > production environment, I'll probably match that in dev. If they > decide LT$ is the way to go, using the JDK will cost nothing for > my dev environment anyway. But if OpenJDK and frequent updates > are selected ... phooey. They will decide to stick with Java 8, even though it's EOL. The decision will be made because (a) "there are some incompatibilities with Java 11 which are hairy to untangle" and (b) "Java 8 hasn't caused a breach, yet, so we'll probably be fine". Good luck! I'm having trouble convincing a partner vendor to move from Java *6* up to Java 8. *facepalm* - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvIqB0ACgkQHPApP6U8 pFjKkg//QQ+ewAy0pyGGFvYtTeqQszqp1/ovQf5d1Tbv4NsDUH9iUtssW2PMb0Sa /4NnBgtef9og0o4idn6ZH/2+I+bNx9/9Sp3Hpurosi7IKAuVCDo0IO97ccUqpaBd OEy0giHx8ook91UOxHyCF9XFoAkJn1+DU41qw0pSSqIhAjPNXarRN3Fq3LzG3JEw 6q5yx3/chKuSpGw5ERhda7l7Sevlph0WGqz96Im7lW1Jmz+MQb/4Cigk9pmrhvw9 spJYE75Mp53CN2EWD2Z5k+Br60yL/XecT1VxXgMpVj8azMUMPtPCEUiwEJEy839A vdeN6DDWbcjwNcyo9EOWt4yVI5t2cx7uc9eGtqrQTEREKHcrn+7ltKkr8bwRE7nz EUiTC3uamhdCu6nRfiniSefCL3JXPZOXyeD0zUZBSK2HqWNEpWbFP8cAIHOhHHgY w0qAOl52wDY+VeIw75raGk4AmjP/z4OpShLjp7Z6QD+mHhVkqQXQTuEmh6qptjQ7 SYEoOqqNurPK+T4R2pvYxQtydBqNi5dOQQ2G2dz7Wogq8imFEGYp+h0M2KDkXGyi bLWv+AXQhJ+kdydbwbk1e7pH6zsxdGXwNCnU09bUhFSg4QoHqi3ngEkL5yL0mXz9 WQPYOnJcWgUrnEXwGhj3NKPMw2ivIAhz8ZvFEOsyOVwuWdEpjhg= =lc0c -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
