So there I was reading the latest ISC Diary entry, on the evils of Java as it impacts malware resistance, when I see it close out with this:
I heartily support that third point.
Being a sysadmin I have seen more than my fare share of appliance configuration utilities written in Java. And had those same utilities crap out on some minor point-rev update, or major update (1.2 to 1.3 was particularly traumatic, though 1.5 to 1.6 had it's own issues). And lived with the hell of two must-use utilities with opposing Java requirements.
Things are a bit better these days. Random appliances mostly come with nice html-GUI these days, which is very welcome. But there is legacy to consider...
Take, for a not exactly random example, a certain Ethernet switch model we use a lot of. It has a web-GUI to go along with the traditional CLI interface. This web-GUI loads a Java applet. I don't know how this Java applet behaves with modern Java because like the stylish sysadmin I am, I'm exclusively a CLI user when it comes to switch configuration. However, there is only one of me at this job, and my backup is a developer who has no other experience with switch configuration. He uses the Java applet exclusively because it's self documenting and makes sense, and allows him to be immediately productive.
If this particular Java applet had a problem with, say, Java 1.6u24 and higher, we'd have to wait a long, long time before we could get any patch in to update it. If a patch would even be produced. This particular switch model is getting on towards EOL, and the pace of switch OS updates has slackened quite a bit in the last year. The vendor would probably not issue an update just because the maximal Java version the applet will run in is no longer the latest, largely because there is an 'easy' workaround: use the CLI like most network engineers do.
And even if we did get a patch like that, we'd have to work in a major outage to get all the switches updated just so our admin users can use modern Java. Given the costs of downtime, us admin users would likely be told to just lump it.
It is for reasons like this that I've adopted a work-around of my own. Keep a VM that I use for admin-duties on which I keep older Java versions around, install ancient configuration utilities, and other such easy-to-get-old detritus of what I do, and never do general web-browsing from that VM. This reduces the attack surface, and so far I've been lucky enough to avoid malware incursions on my own stuff.
It is for reasons much like this one that many (if not most) sysadmins of some experience shake their fist whenever they get a new thingy that requires a Java applet for configuration, and hate on Java in general.
Bottom line:
If you don't need Java JRE on your PC, get rid of it.
If you need it, patch it.
If you can't patch it because some silly application is not compatible with the patch, kick the [beep] of whoever supplies that application.
I heartily support that third point.
Being a sysadmin I have seen more than my fare share of appliance configuration utilities written in Java. And had those same utilities crap out on some minor point-rev update, or major update (1.2 to 1.3 was particularly traumatic, though 1.5 to 1.6 had it's own issues). And lived with the hell of two must-use utilities with opposing Java requirements.
Things are a bit better these days. Random appliances mostly come with nice html-GUI these days, which is very welcome. But there is legacy to consider...
Take, for a not exactly random example, a certain Ethernet switch model we use a lot of. It has a web-GUI to go along with the traditional CLI interface. This web-GUI loads a Java applet. I don't know how this Java applet behaves with modern Java because like the stylish sysadmin I am, I'm exclusively a CLI user when it comes to switch configuration. However, there is only one of me at this job, and my backup is a developer who has no other experience with switch configuration. He uses the Java applet exclusively because it's self documenting and makes sense, and allows him to be immediately productive.
If this particular Java applet had a problem with, say, Java 1.6u24 and higher, we'd have to wait a long, long time before we could get any patch in to update it. If a patch would even be produced. This particular switch model is getting on towards EOL, and the pace of switch OS updates has slackened quite a bit in the last year. The vendor would probably not issue an update just because the maximal Java version the applet will run in is no longer the latest, largely because there is an 'easy' workaround: use the CLI like most network engineers do.
And even if we did get a patch like that, we'd have to work in a major outage to get all the switches updated just so our admin users can use modern Java. Given the costs of downtime, us admin users would likely be told to just lump it.
It is for reasons like this that I've adopted a work-around of my own. Keep a VM that I use for admin-duties on which I keep older Java versions around, install ancient configuration utilities, and other such easy-to-get-old detritus of what I do, and never do general web-browsing from that VM. This reduces the attack surface, and so far I've been lucky enough to avoid malware incursions on my own stuff.
It is for reasons much like this one that many (if not most) sysadmins of some experience shake their fist whenever they get a new thingy that requires a Java applet for configuration, and hate on Java in general.