In the past few months Oracle have released a variety of changes to the Java Runtime Environment (JRE) that have impacted EditLive and any other Java-based browser component. The purpose of this article is to provide our customers with some background on what happened along with our current recommendation(s) for running EditLive in your enterprise. This article will cover the three most significant changes to Java 1.7 since the release of Java 1.7 u25. These are:
- Changing Security / Manifest Packaging Requirements
- The Security Baseline and its impact on the Security Level in the JRE
- Introduction of the Exception Site List
Changing Security / Manifest Packaging Requirements
When we package EditLive for distribution we “sign” our code and package it in a way that gives EditLive certain permissions while running. In the past few months we have seen two such changes.
When Oracle released Java 1.7 u25 they required us to change the way we package our product. We complied with these changes and released new packaging for EditLive.
When Oracle released Java 1.7 u45 they introduced new packaging requirements that were in direct conflict with the requirements that were introduced in Java 1.7 u25. Unfortunately, Java 1.7 u45 would not run EditLive if the packaging introduced in Java 1.7 u25 was left in our product. This created a catch-22 for EditLive in that a single distribution would not run on Java 1.7 u25/40 and Java 1.7 u45.
In January 2014, Oracle released Java 1.7 u51. This release will allow the security packaging from both Java 1.7 u25 and u45 to coexist effectively allowing us to release a single package that will work without prompts in every Java 1.7 release except u45. (If you require support for Java update 45, please contact ephox support)
The most recent releases of EditLive (184.108.40.206+ and 220.127.116.11+) are packaged in a way that they will run on all Java 1.7 JREs. If you are on an older release of EditLive we strongly recommend updating to the latest Cumulative Fix Release.
The Security Baseline and its impact on the Security Level in the JRE
When Oracle releases updates to the JRE they may (depending on what changes were made) update the security baseline. In recent months the security baseline has changed 3 times:
- Java 1.7 u25
- Java 1.7 u45
- Java 1.7 u51
- Java 1.7 u55
Note Java 1.7 u40 is on the same security baseline as Java 1.7 u25 as there were no security fixes in that release. The same is true of Java 1.7 u60 - its on the same baseline as Java 1.7 u55.
Oracle’s expectation is that users should always be on the latest security baseline. Starting with Java 1.7 u25, if you are not on the latest security baseline LiveConnect is disabled when the JRE is using the High (default) or Very High security levels.
LiveConnect is how the browser interacts with EditLive. If LiveConnect is not functioning EditLive will appear in the browser but the ability to load content into EditLive or extract content from EditLive (via our APIs) no longer functions.
Your options two address this are rather simple:
- Update to a JRE on the latest security baseline
- Adjust the security level in the Java Control Panel to Medium
Oracle would strongly suggest that updating to the latest JRE is the correct answer. There are certainly situations where that is not possible (e.g. other applications require older JREs) and in those cases adjusting the security level to Medium will allow EditLive to use LiveConnect.
Introduction of the Exception Site List
While the two issues above caused issues, the introduction of Java 1.7 u51 has been a good move in the other direction. It is more accommodating regarding the packaging of EditLive however, the need to be on the latest Security Baseline to use LiveConnect has remained.
One remaining issue is that for many corporate customers the “always update to the latest JRE” philosophy is simply not acceptable or feasible. In Java 1.7 u51 Oracle introduced the Exception Site List to help address this issue.
Starting with Java 1.7 u51 you can “whitelist” sites that you use so that the JRE will no longer block those sites from working (even after a JRE update is released). Oracle describes this on their site:
"The Exception Site List is a way for end-users to control their own application whitelist and continue using RIAs that could not be timely updated to follow previously announced security requirements. The Exception Site List provides a way to continue using a RIA but is not intended as a way to remove all warnings for the user. End-users will still see important prompts, but those prompts will no longer block."
While this feature won’t help you until you update to Java 1.7 u51, it will help corporate customers manage the process of updating the JRE while still allowing employees to access critical business applications. You can learn more about this feature from Oracle:
Note: The Exception Site List is a workstation-level setting.
Ephox’s Current Recommendations
Given the recent fluctuation with the JRE we do get customers asking “so what should I do at this point?”. To fully answer this we will look at both the JRE and EditLive itself.
JRE - If you are on Java 1.7 we would recommend that you update to Java 1.7 u51 or later. This JRE is the most “packaging tolerant” of any of the recent JREs. The Exception Site List allows you to manage future updates in a far more “corporate friendly” manner.
EditLive - If you have not updated EditLive in 2014 we recommend that you grab the latest EditLive Cumulative Fix Release from our web site (http://ephox.com/download). The latest releases of EditLive V8 and EditLive V9 are packaged such that it will work in all Java 1.7 updates - please note that u45 will prompt to allow EditLive to run (this cannot be eliminated if you choose to remain on u45).
If you have any questions regarding this information please open a support case with us and we can help you get through any remaning concerns/questions.