To go along with my earlier post about automating Oracle Java 7 updates, I’ve also posted a script to download and install the latest Java 8 update from Oracle. The method is identical, with the exception of referring to Java 8’s SUFeedURL value in Java 8’s /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist file.
For more information, see below the jump.
Something I’ve wanted to do for a while was to write a script to download and install the latest Java 7 update from Oracle. I’ve been using AutoPkg to download the latest Java 7 updates using AutoPkg’s OracleJava7 recipes, but I wanted to develop a script that would do the following:
- Download the latest Java 7 installer from Oracle’s website
- Install the latest Java 7 update
- Clean up after itself
Oracle didn’t make this an easy task, as the download URL seems to change on a per-update version. AutoPkg handles its update task by scraping Oracle’s manual download page for the current correct URL to use.
Oracle does provide a Sparkle-based update mechanism for Java 7 on OS X, so I wanted to see if there was a way to leverage that to pull down updates. The only address I could find in that regard was the SUFeedURL value included in Java 7’s /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist file. I checked that value using the following command:
defaults read "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info" SUFeedURL
The output I received for Java 7 Update 67 was the following:
I decided to see what output would come back from Oracle’s site when accessed, so I used the following curl command to see what was returned:
/usr/bin/curl --silent https://javadl-esd-secure.oracle.com/update/mac/au-1.7.0_67.xml
The following XML was returned and I was gratified to see that it contained a download link to a Java 7 Update 67 disk image.
One of the important things I was able to establish is that the XML address embedded with Java 7 Update 67 is not special in this regard. As part of my testing, I verified that using the SUFeedURL value for Java 7 Update 15 and 65 will also work to pull the address of the latest Oracle Java 7 installer disk image.
Using this information, I was able to build a script that can download and install the latest Java 7 update. See below the jump for details.
It’s been a long time coming, but Java 6 on OS X has hit the end of the road for updates. Mike Swingler has posted a message to the Apple java-dev list that confirms that no further Java SE 6 updates are available for any platform, including OS X. Java for OS X 2013-005 and Java for Mac OS X v10.6 Update 17 are the latest versions available and install Java SE 6 build 1.6.0_65.
As part of this post, I’d like to say thanks to the Java folks at Apple for going above and beyond. Apple’s last Java 6 update was released in Oct 15, 2013, which was a full eight months after Oracle discontinued updates for other platforms. This allowed some vulnerabilities in Java 6 to be addressed that otherwise wouldn’t have been.
For those who need them, download links for Java for OS X 2013-005 and Java for Mac OS X v10.6 Update 17 are available below:
Oracle’s Java 7 Update 51 has introduced new security requirements for browser plugins for applets and web start applications. However, not all applets are able to run using the new requirements. To help with this, Oracle has included a way to whitelist specific sites using Java 7’s new Exception Site List. This allows the applets and web start applications hosted on the specified sites to continue to work, even if they don’t meet the new security requirements in Java 7.
On Mac OS X 10.7 and higher, the Exception Site List is a plaintext file named exception.sites, which is stored in /Users/username/Library/Application Support/Oracle/Java/Deployment/security.
To help Mac admins manage the Exception Site List, I’ve written a script which is designed to add websites to Oracle’s Java 7’s Exception Site List without overwriting existing entries. For more details, see below the jump.
Older versions of Java applets used by Juniper’s SSL VPN may be blocked from working properly by security changes in Java 7 Update 51. When the applet is blocked, an error message like this will appear:
SecurityException: Missing required Permissions manifest attribute in main jar: https://server.name.here/dana-cached/sc/JuniperSetupClientApplet.jar
The root cause is that Java 7 Update 51 now requires the existence of the referenced permissions attribute, along with a requirement to code sign all Java applets. The applets used by older versions of Juniper’s SSL VPN do not include the permissions attribute.
The fix is to update the SSL VPN with Secure Access (SA) version 7.1R17, 7.3R9, 7.4R7, 8.0R1 and later versions. The applets included with these versions have the needed permissions attribute. Until the VPN server is upgraded, Juniper’s recommended workaround is use Java 7 Update 51’s Exception Site List feature. To help with this, I have a post showing how to add sites to the Exception Site List in the Java Control Panel settings.
Oracle released Java 7 Update 51 on January 14th. As part of the installation, the Java security level is set by default to High. With this security setting, self-signed and unsigned applets are blocked from running. This can be verified by going to http://javatester.org/version.html, as this site uses an unsigned Java applet.
Fortunately, it appears that there are a couple of ways to fix this. See below the jump for details.
Along with Mavericks‘ release today, Apple released Safari 7 (included with Mavericks) and Safari 6.1 for Mountain Lion. Both versions of the Safari browser are having issues connecting to my work’s VPN. When connecting to the VPN, it will try to install the Network Connect client software then fail with the following error:
An error occurred while extracting one of the Network Connect components
Mac OS X 10.6.8 and 10.7.5 do not have Safari 6.1 available as an update of this time, so connecting to the VPN using Safari on those OSs should be unaffected.
I’ve verified that connecting to the VPN with Firefox 24 works for both 10.8.x and 10.9.x.
For now, it appears that using Firefox to connect to Juniper VPNs is going to be the workaround for this issue until we can get a fix from either Juniper or Apple. Google Chrome is a 32-bit browser, which prevents it from being able to work with Oracle’s 64-bit Java 7.
Based on what I’m seeing, it looks like Safari 6.1 and Safari 7 introduced a new sandbox for browser plug-ins, replacing the previous Java whitelist. At this time, it does not appear that Juniper’s software is able to work with this sandbox.
An issue that I’ve been dealing with for a while has been that Oracle’s Java 7 did not run natively in VMware Fusion. VMware had created a patch for OS X VMs, but it was only designed to be run in OS X VMs running 10.8.x.
As of today, that issue has now been resolved. With the release of Java 7 Update 40, Java 7 now runs natively in VMware Fusion OS X VMs running 10.7.5 and 10.8.4. Thanks to the OpenJDK team, Oracle and VMware for their work in getting this fixed.
Apple put out two advisories on August 29th about Java:
The latter advisory is especially noteworthy to Mac admins, as that means that Apple’s XProtect was updated to block older versions of Java. That said, XProtect was not updated after the latest round of updates in June 2013, so those versions were not previously set in /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist as the minimum allowed versions. See below the jump for more details.
Installing Apple’s updated Java for OS X 2013-004 and Java for Mac OS X 10.6 Update 16 over previous versions
As part of dealing with the issues caused by the initial versions of Apple’s Java for OS X 2013-004 and Java for Mac OS X 10.6 Update 16, Apple has recommended installing the revised version of the updates overtop of the existing update in order to replace the problematic Java builds.
The fixed Java builds are the following:
Mac OS X 10.6.x: 1.6.0_51-b11-456-10M4509 (currently installed by Java for Mac OS X 10.6 Update 16)
Mac OS X 10.7.x – Mac OS X 10.8.x: 1.6.0_51-b11-457-11M4509 (currently installed by Java for OS X 2013-004)
If you’ve already installed Java for Mac OS X 10.6 Update 16, it appears that there’s no way to use the softwareupdate tool to install it again. For 10.6.x Macs that had previously installed Java for Mac OS X 10.6 Update 16 and got the problematic build, the installer will need to be downloaded from Apple and then installed on your 10.6.x Mac.
For 10.7.x and 10.8.x however, there’s a way to override the install check that softwareupdate uses which is specific to Apple’s Java updates. By setting the JAVA_INSTALL_ON_DEMAND environment variable for softwareupdate, you can force softwareupdate to install the latest Java update from Apple. This allows you to leverage softwareupdate to re-install the updated Java for OS X 2013-004 over an existing Java for OS X 2013-004 installation that included the problematic Java build.
Michael Kuron posted a script to the MacEnterprise list that I’ve modified. The modified script works pretty well in my environment and does the following:
1. Checks the current OS to see if the Mac is running Mac OS X 10.7.x or later. If not, the script will exit and display the following message:
Not supported on this version of Mac OS X
If the Mac is running 10.7.x or higher, the script runs the following actions:
2. Checks the Java version and displays the results
3. Sets the JAVA_INSTALL_ON_DEMAND environment variable
4. Uses the softwareupdate tool to check for and get the name of the latest Apple Java update for 10.7.x and 10.8.x
5. Installs the latest available Apple Java update for 10.7.x and 10.8.x
6. Checks the current Java version and displays the results
For those interested, the script is available on my GitHub repo: