The recent and critical Java CVE necessitates that everyone either uninstall, remove or update Java immediately.
My employer uses a lot of Java, and removing or uninstalling it across thousands of machines just isn’t possible. We also support 4 platforms for each new release (in 32-bit and 64-bit), so pushing out a new version of Java involves downloading, unpacking, deploying and releasing 8 different builds per version. Today’s recent news, means I have to download and deploy 16 separate builds of Java for 1.6u38 and 1.7u11 to meet the security requirements and keep us current.
Oracle’s website is painful enough to navigate, and downloading new Java releases from their site requires an interactive click-wrap agreement to be acknowledged before you can continue with the process; before the download links become visible or active in a browser to be clicked. When you attempt to download, you’ll be presented with a page that contains this:
To download an Oracle Java release from here, you have to go to their Oracle Java Download page, click “Accept License Agreement”, and then click each version of Java you want to download, to download interactively using your desktop browser to your desktop.
In a word: Ugh.
If you need to use those on a UNIX or Linux host as I do, you then have to then take those downloads that you’ve pulled with your browser, and scp/pscp (with PuTTY or similar) or rsync those over to your UNIX/Linux machine from your desktop.
Could this process possibly be more convoluted and complicated?
But there’s a solution: Wget! (with some secret sauce)
Read the rest of this entry »
The corporate VPN software I use to get onto the work LAN uses a Java-based “viewer” applet in a browser to get to my desktop machine (think “remote desktop”, but using a browser + Java applet), is an HTML page which uses Flash to deliver a Java applet, which then is used to do the “remote desktop” functionality. Yes, you read that right… HTML delivers the Flash which delivers the Java.
But I’ve recently rebuilt one of my Windows machines here at the office to include a 64-bit version of Windows Server 2003, and because of that, it’s been a bit of a struggle to find and reload all 174 applications I was previously using on the previous machine, in 64-bit format, as well as the 64-bit drivers necessary to support the peripherals (network, disk, scanner, printer, etc.). One of those was making sure my browsers were functioning correctly for everything I use it for, including accessing the VPN when I work remotely.
To that end, I installed the 32-bit version of Firefox for Windows, then the 32-bit Java SE Runtime 6u13, but that didn’t let Java applets to function in Firefox at all. about:plugins showed that Java u13 was seen and enabled as a valid plugin but applets would not work in Firefox. I tried using the Java Applets Test page, and it would just show a blank region where the applet should have been.
After I installed both versions of Java onto the machine, I decided to try the VPN connection using Internet Explorer, which worked, so I knew Java and Java applets were functioning correctly.
After some poking around, I found that there was one minor tweak that was required to get the Java applets to function in Firefox (either bitness).
While MSIE is loaded, go to the Java Test page and while there, you’ll see a Java applet icon in your Taskbar. Right-click on that, and you’ll see something like the following:
In the Java Control Panel, there is an option under (Advanced | Java Plug-in) labeled “Enable the next-generation Java Plug-in (requires browser restart)”. Disable (uncheck) that checkbox to enable Java to function correctly with Mozilla, as shown below:
Also, verify that Mozilla is enabled under “Default Java for browsers”, as shown below:
Click Apply, click Ok, then launch Firefox and try your applet again. You should see something like the following:
That’s it, you’re done! Now Java u13 should work fine in Firefox on 64-bit, without any issues.