This is a misleading headline, since the article is referring to the security of old versions of Java. I guess "Outdated Software Contains Known Security Holes and Will Probably Never be Patched, Experts Say" is not as catchy of a title.
How is this news? The more popular a piece of software is, and the longer a specific version of it has been in use, the more bugs will be found and exploited. Duh?
While I agree that the article is highly misleading, I don't think this is a complete non-issue. I imagine there are still a lot of organizations (especially those in developing countries) that have systems that were setup a decade or so ago with XP, IE7, Java5, etc. and haven't been properly upgraded.
It is alarmist and misleading, but it is also something that will continue to detract a new user's view of the JVM as a platform, like startup time. This is more a PR battle than anything else.
>> It is alarmist and misleading, but it is also something that will continue to detract a new user's view of the JVM as a platform, like startup time.
No, it's just alarmist and mis-leading, the answer is upgrade. That's the answer for Java, Operating Systems (example Windows XP), Smart Phones, it's how software has worked for decades. There's nothing new about it.
Someone got a wild hair and posted a sensationalist title that JavaScript people on HN would like and want to jump on.
So in terms of client-side startup it can become a pain, because if you're starting and stopping a jvm all the time you tend to feel it.
You encounter these problems if:
- People write unix-style tools on the JVM (imagine if ls was a Java program). Thankfully almost no one does this, but...
- When you use tooling for things that involve JVM languages, such as Clojure's lein or Scala's sbt. Starting lein / sbt is annoyingly slow. Using Scalaiform to format scala code takes a noticeable chunk of time because it's booting up a jvm each time. So noticeable that as much as I'd like to have it happen every time I save a file it makes SublimeText way too choppy.
This is less noticable on faster computers (my current work box is a i7 laptop with 12GB and an SSD) but on older computers it's still a real pain. Working with Clojure on a 2009MBP can be an exercise in frustration.
You are assuming there is only ONE JVM, which could not be further from the truth.
There are JVMs on the market that compile to native code, and others that cache the JITed code from previous executions. Aonix and Websphere Real Time JVMs are two possible examples.
I really think developers should broaden their horizons. Oracle's JVM is only the reference implementation.
The one you have to use when you don't get to place all of the working code in jeopardy of not working in random places on your own initiative at the place that you work. WHich almost always means Sun's JDK or OpenJDK.
I know there are a bunch of JVM's. Just trying to make the point that for most people in most organizations, there's really no choice in the matter, leaving only Oracle's JVM or the OpenJDK - due to the weight of potential compatibility issues, need for retesting, uncertainty about future support/viability, etc. That's a large organization for you, I'm sure it's different at smaller shops and I can envy that.
Anyone who has attempted to run an applet on any modern browser in the past 6 months will know it now involves a lot of work -- clicking through several dialogs and warnings even if you do have the latest version.
If you don't have the latest version, some browsers make it impossible, and others let you go ahead only after you acknowledge that you're putting your immortal soul in dire peril (or something along those lines).
Java on OS X will self-disable if you don't use it for a while, so then you have to figure out how to enable it, again, if you even figure out what has happened.
In Safari even when everything is enabled you see a gray box with small text saying something like "plugin disabled" in it. You have to click the small text (though it doesn't look like a link or button) to access the menu to enable it and continue.
I suppose they must be targeting corporate machines running XP and IE7 or something like that? I don't think most other people are succeeding in running legitimate Java applets, let alone anything that would be a security risk.
>Who exactly is exposed to these flaws? Anyone who has attempted to run an applet on any modern browser in the past 6 months will know it now involves a lot of work -- clicking through several dialogs and warnings even if you do have the latest version.
Some hundrends of millions of people still running XP, Windows 2000 or Vista, with IE or Firefox?
As someone who works in a coporate-ish environment and has had to get Java running on 10.7 and 10.8 with Safari, I am surprised someone who does not have a background in systems administration could get it working.
Unless the bulk of the population knows what symlinking is, but I doubt it.
Yes, and they have no running Java at all unless they've either jumped through some serious hoops to get it working again after Apple disabled it, or they don't install security updates.
This is only true for Browser applets - granted that's the worst security hole. Coding in and running Java applications is fine on 10.6, but you have to stick to Java 6
For people downloading & running untrustworthy applications, Java has nothing to do with their security problems.
The security holes are only an issue in the context of Java applets -- Java applications don't run in the sandbox anyway (i.e., they're like other applications).
So, correct me if I'm wrong, but aren't these issues all around the sandbox functionality of applets?
So specifically, to exploit these, you write a dodgy applet, then convince users to run these applets locally (by hijacking websites or whatever), whereby you break out of the sandbox and do bad shit.
So then, in terms of how Java is generally used: on servers, on android, to execute code that runs locally on your box outside of a sandbox anyway (e.g. minecraft) these issues are in fact complete non-issues?
It seems to me that if they just split off the applet part into its own thing the world would be a far better place.
Many of the bugs relate to the functionality of WebStart, which has nothing to do with applets. Basically, if Java is enabled in your browser, visiting a web page can start a full-blown Java application (not an applet) without requiring user interaction. This Java application could escalate privileges to root your system. This type of exploit is included now on a number of exploit systems, like Metasploit, that can be deployed easily by "script kiddies".
You are wrong, the article isn't about the merit of applets, these issues deal with a company that doesn't want to support software that is deployed on millions of PCs.
Long-time Java developer here saying I mostly abandoned ship several years ago. Still work doing some Java dev, but have mostly switched to Ruby, because Scala is unreadable to me and I've not found anything else I like as much as Ruby yet. Oracle really fucked things up, if for no other reason than they've poorly managed security issues. They let the government tell people to uninstall Java from their browsers. That is fucked up. It's like they don't even care and want it to die.
Well, I have a Java system for playing interactive fiction games on the desktop. When people started playing them on the browser, the obvious way to adapt my system to that functionality was an applet. That way I could reuse 99% of the code, and they could get the same functionality as on the desktop.
Sadly, now it's getting harder and harder to run applets. And I'm not going to code a different web-based version of my system (which would involve not only rewriting a lot of code, but finding different libraries to handle MP3, OGG, SVG graphics, etc.) so I suppose my system will just slowly fade into obsolescence.
For some things, applets are still the best choice... or would be, if users were not aggressively discouraged from using them due to what amounts mostly to PR campaigns (as i.e. Flash is by no means more secure than Java applets, and browsers don't make you click through four layers of scary dialogs to run it).
What I hate about coding projects for end users that need to run on shiny platforms (like the web) is that you always get caught on politics. Stuff like company X not allowing running software written in language Y on platform Z so as to promote its own platform, and making you port everything several tiems. Or company X including a crippled distribution of software Y because it hates company Y (this happened with Ubuntu and Java and has brought me scores of bug reports to handle). I guess my future hobby projects will be in C/C++ and directed to technical users that don't expect to run their machine learning software (for example) on a tablet browser...
Because this project is already there, I started it in year 2000 when most of those technologies didn't exist. I would need to code everything again in JS, and we are talking about more than 150 KLOC. Plus libraries that might not be available in JS. And then I would have two separate versions to maintain. No way I'm going to do that, I'm not getting paid for this project and I don't have enough free time.
With Java on the other hand, I had a desktop app and an applet sharing the vast majority of the codebase, only very specific parts of the code (a small part of the UI and I/O code) differ. This is what was allowing me to maintain the project and support both desktop and browser, until the applet paranoia growed out of proportion and browsers put applets in permanent quarantine.
Of course, if I started this project now rather than in 2000, I would probably make different decisions regarding language and technologies used. Although it would still be a bit annoying not to be able to use Java. It's not my favorite language, but I definitely prefer it to JS by a mile.
I was thinking more about the fact that you had switched to C/C++.
I agree that re-writting an app of that size is a giant PITA.
You could always use GWT though, and compile Java to Javascript. Altough you would probably have to re-write code as you're not targeting an applet anymore.
Long time Java developer here as well, 1 out of 10 projects in my experience had some part of the application in Applets, and this one project is usually a legacy one.
No sane Java developer would start a new project with Applets.
This is in sharp contrast to my workplace where I often hear, "we used Java because we don't care about performance." I guess C++ programers are the master race :-)
AspectJ would probably be the most widely broken dependency, even with UseSplitVerifier enabled. Version 1.7 of AspectJ fixes the issue, but most corporate IT consumers aren't in a position to update it themselves.
Please also disable the .jnlp extension handler included with many older browsers, and activated by installing Java from the Oracle (and formerly Sun) Java virtual machine.
Using Java WebStart, the .jnlp file can specify which version of the JVM to use when running the application (not an applet, but a full-blown Java application).
How is this news? The more popular a piece of software is, and the longer a specific version of it has been in use, the more bugs will be found and exploited. Duh?