Kevin Kempf's Blog

August 7, 2014

R12.2, Oracle Java, Microsoft, Google and Security

Filed under: Java, Oracle, Windows 7 — kkempf @ 11:51 am


The Playing Field

It’s no secret Google hates Microsoft (M$) hates Oracle hates Google hates Oracle hates Microsoft.  But EBS users are caught in the crossfire this time, and it’s not pretty.

M$ recently announced here they were going to start blocking Java launches out of IE.  You know, because they’re looking out for us.

Java started squalking about unsigned Jar files awhile back, but if your version was old enough, you wouldn’t see this message because it was too dumb to know it.  It also pesters you incessantly if you’re not running the latest version.  Always.

Google started stopping Java from running in Chrome which I noted here.  It was technically never certified with Oracle EBS, so I hold them least culpable at the moment.


I appreciate that all of these players are protecting their own interests and implementing these changes in the name of security.  People complain about Java security?  Great, now Oracle will issue an update every week, and if you’re more than 2 updates behind it will nag you forever.  Launching EBS which doesn’t have signed JAR files?  Big scary window pops up warning the user.  Want to run old Java on Windows 7?  Microsoft says nope.

I’m in the middle of an R12.2 upgrade.  I have the luxury of taking the time to go get a certificate from Thawte and sign my jar files, and test it.  The truth is that it’s pretty easy.  But so is the process of getting a certificate.  Meaning, nothing against Thawte, but by signing my jar files all I’ve done is satisfy the JRE plug in.  I haven’t really enhanced my security, in my opinion.  Same thing with upgrading to the latest version of Java.

Meanwhile, here in the real world

I work for a manufacturer.  The floor workers who interact with Oracle EBS don’t know/care/understand what Java is, what a signed jar file is, what version of Java they’re running, etc.  They just want to get into Oracle EBS.  We’re not internet-exposed.  Sure there’s risk of someone exploiting a security hole, but it would probably have to come from the inside.  This is a known risk we’re probably more willing to take than the risk of having to deal with hours and hours of confusion every time M$ makes a unilateral decision about Java, or Oracle delivers yet another Java update.   We’ve been running EBS 11i on Java 1.6_12 for over 5 years now.  Never caused a problem.  It’s ancient, but it works.  Much like, I suspect, many companies, we have a lot of legacy Java running.  The effort required to push a newer version of Java to these machines is not insignificant, since they’re all locked down on the manufacturing floor.

Battle of the sexes

I’m sick of it.  Java consumers (and I’m not talking about coffee here) are stuck in the crossfire between M$ and Oracle.  Here’s what I see happening:

1. We regression test and deliver R12.2 with Java 1.7.0 update 67 in 6 months

2. Oracle issues 25 more versions of Java 7 thus every user gets the “Update (Recommended), Block or Later” dialogue box

3. Some users block, some update, some say later.  66.66% of these scenarios cause IT problems

4. Microsoft, not to be outdone, declares Java 1.7 update 67 obsoleted, and thus adds it to a block list

Managing the Mess

Sure, we can manage Win7 updates through policy, and the same for Java updates.  But are we actually improving security, in any way?  Or just creating busy work for ourselves, where the version which runs on our isolated network is largely immaterial?




Blog at