Oracle ordered to admit on its website that it lost the plot on Java security Oracle bungled the security updates of its Java SE software so badly it must publish a groveling letter prominently on its website for the next two years. After gobbling up Java along with Sun in 2010, Oracle's software updates for Java SE would only affect the latest version installed. If you had multiple versions of Java SE …
Before I retired, I managed systems on which several Java versions were, in fact, required.
1. Some commercial products were written to a particular Java version. The vendor would not support operation on later versions. As this was a US DoD agency, we were not allowed to run unsupported software and nobody in the chain of command would even come close to authorizing us to support a vendor product (for which we had no source code or ability to develop fixes). Running unsupported software was a Category I finding that technically required removing the product from any DoD network. This was a common case, and I was acquainted with numerous workstations and servers that had three or more Java versions installed and in use.
I recall a case in which we tested of a non-Oracle product (not itself obsolete) that was said to depend on Java 6, then out of support. Java 7 was available and we tested the product against it thinking that in view of the frequency of Java vulnerabilities it might be better to run an unsupported combination of supported products than a flatly unsupported Java version. The question never arose, however, since our testing indicated that the dependency was quite real, and the final outcome was a much slower and more costly product upgrade to the newer version.
2. During software development it often was necessary to maintain both current and future versions of a product on the same server. They sometimes required different Java versions, since we tried to target new development to software environments that were not at or approaching obsolescence.
Your points are all valid. But I think the FTC was more concerned about Grandpa and cousin Bubba who can barely turn on a computer. The software they have installed is likely to be consumer oriented not business oriented. And they are not likely to understand that nuances of updating something like Java or the JVM. At best they would be lucky to know they Java on their systems.
What't the real difference between "consumer" and "business" oriented?
My father, who is 77, and can barely use a PC, has to use our revenues service Java software to file his taxes (or would have to pay someone to do it on his behalf). Until recently the validation, signing and upload software the government agency made available (and mandatory to use) was written for Java 1.5 and refused to work with any newer version (I tried). Moreover not one of its developer knew how to install a "private" JRE for its own use, instead of requiring to install one system-wide.
Actually, it Sun/Oracle had removed older versions, that application would have stopped working and my father would have been unable to file tax data. Great news for "consumer" Grandpa and Bubba... even outside of business you may rely on some critical applications.
Also, there are many Java developers who have never heard of forward compatibility (avoid hacks that aren't going to work in the future), or perform silly versions checks "just because", and never heard of self-contained applications (https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html - if you really need to control what JRE you're using). Also, developers (and users) who never upgrade applications (and themselves...), even when they could.
A couple of years ago we started a company-wide cleanup of outdated and dangerous software, Java included. One day getting back from the company HQ, at the airport I overheard some people damning those guys who were creating trouble asking them to remove Java versions their applications relied on, forcing them to upgrade or look for alternatives - after a while I understood they were working for a different division of our company...
Indeed we have internal apps that Java Updates still break. Works on Java 8 Update 60, but not Update 65. WTaF?!
I would rather the installer KEPT the previous version as well as the new version, whilst wiping older versions. That would allow a simple "switch to previous version" functionality for these situations.
Instead they wiped the known-working version, and kept the cruddy old versions.
But they're still allowed to install crapware unless you uncheck it as part of the install?
To expand on what Kernel said there, crappy Enterprise software (okay, that's redundant) often requires a very specifically broken version of JVM installed. So you need this version of this bloated piece of issue tracking crap, that version for this bloated document CMS piece of crap, etc, another version for this terrible UML abomination, etc. One set of security fixes and they stop working!
But, the better way to do this is to require a manual install of the separate versions side by side where it's required rather than to just leave all the broken versions lying around.
"To fix this problem, visit http://java.com/uninstall, where instructions on how to uninstall older versions of Java SE are provided. This webpage also provides a link to the Java SE uninstall tool, which you can use to uninstall older versions of Java SE. You may also go to http://java.com/uninstallhelp if you have any additional questions or concerns."
except that the uninstaller doesn't bloody work if you're not running bloody Windows. From the page in question:
"This operating system is not supported.
The Java Uninstall tool will only work on Microsoft Windows.
Information for other operating systems:
Uninstalling Java on Linux
Uninstalling Java on Mac
Uninstalling Java on Solaris
Learn more about the Java Uninstall tool"
May the fleas of ten billion camels infest Larry Ellison's crotch.
@James O'Shea "May the fleas of ten billion camels infest Larry Ellison's crotch." - You are too kind for Leisure Suit Larry. While users of Linux and Solaris are generally technically literate and can figure out how to uninstall older Java versions, With Linux, one should know how to use your distro's package management tools. I suspect most Apple users are not.
"With Linux, one should know how to use your distro's package management tools. I suspect most Apple users are not."
Having tried to remove Java from OS X, it isn't for the faint of heart. I wasn't 100% confident that I'd removed all traces of Java until I did a complete wipe and reinstall from scratch.
Neither was it easy as it should have been on the only Linux distro where I tried to get rid of it. I gave up because it was going to take out too many other components. That was a few years ago though (OpenOffice contained Java dependencies, even if you didn't intend to use those bits).
"technically literate and can figure out how to uninstall older Java versions, With Linux, one should know how to use your distro's package management tools."
Agree, except that Oracle still haven't figured out how to package Java properly. The RPMs are average at best, and if you are expecting Deb packages, best of luck to you.
Fortunately a lot of decent software works happily with OpenJDK.
You get the bin, extract it to /opt/java/##/jre_$version (where ## is 32/64 depending on the version).
Then you set up /etc/alternatives/whatever to follow /opt/java/##/jre_latest/bin/whatever (where whatever is java, javaws, jControl, etc.) and a symlink in /usr/lib/mozilla/plugins/libnpjp2.so to jre_latest.
For older versions, you make launchers directing to the specific java version with the specific program.
Furthermore, you can set up more symlinks (for 1.7latest, 1.8latest, etc.).
This always worked for me and to be honestly speaking, I don't see why you would bother with RPMs or DEBs when you know that this can break dependencies and that this will not be enough since you'll always need a specific Java version at some point.
You get the bin, extract it to /opt/java/##/jre_$version (where ## is 32/64 depending on the version).
And as soon as you do that, you are working outside the package manager, so you have to track changes and updates manually. If you forget one - you've got non-updated code on your production box with all the issues that entails.
I don't see why you would bother with RPMs or DEBs when you know that this can break dependencies
Because RPMs and DEBs merely state the dependencies for the package manger to enforce[1]; the dependency is still in the code whether you use automated tools to resolve it or not.
Vic.
[1] You can over-ride that if you know how, opf course, but that's often not a good idea.
Software developers know about the poor backward compatibility of Java versions so they often not only specify a minimum version but fix the Java requirement to a specific version.
I have a customer with a SAN storage connected to SAN switches which in turn is connected to an FC-IP router for connectivity to another site for replication. The SAN storage, SAN switches and FC-IP router each have a web GUI with its own requirement for the Java runtime. The worst is the FC-IP converter which only accepts one specific version.
They recently got new Brocade SAN switches installed which of course require their own version of Java.
The solution is to pick the most important device for the web GUI and use the CLI for the other boxes.
May the fuel tank on Larry's yacht always be filled with sugar.
Oh, you know, as a technically illiterate Mac user I once had to connect my Brother printer to WiFi. Turns out that needed a Java applet. I reluctantly installed Java (intending an immediate uninstall), got my printer connected, but then gradually figured out there was no guaranteed way to uninstall Java, you could only disable the Web plugin.
Which... you could only do as a the current user, not for other users. Unless you had admin rights, which I did, for anything but Java. SUDO? Not enough, apparently.
In hindsight, talking to the printer's config server would have worked from a VM. That seemed like unwarranted paranoia at the time - surely, especially on a nix box, I'd easily remove Java, right?
Lesson learned - I have never seen such a bungled installer. FYI yum or aptget are familiar beasties. So is macports.
Java is just... very special needs. I just neutered it best I could and added another reason to hate that language.
"The Federal Trade Commission, theone nation’s consumer protection agency, has sued us "
Fixed that.
Not that the FTC was wrong, but have to think global readership these days. Or are Oracle going to display an admission of guilt to the US, and serve something different to other areas.
"the US approach to domestic electrical plugs and sockets is dodgy too!"
So is the continental approach. Only the Brits have decent plugs / sockets:
http://i.ebayimg.com/images/i/311189494259-0-1/s-l1000.jpg
https://perryponders.files.wordpress.com/2015/03/plug-annotated.jpg
"the US approach to domestic electrical plugs and sockets is dodgy too!"So is the continental approach. Only the Brits have decent plugs / sockets:
http://i.ebayimg.com/images/i/311189494259-0-1/s-l1000.jpg
https://perryponders.files.wordpress.com/2015/03/plug-annotated.jpg
Uhmm, No, the british plugs are as stupid as the US ones. Encountering one barefoot in the middle of the night will tell you that. The main reason people think british plugs are safe is because of the built in fuse, but the only reason it NEEDS that fuse is because of the stupid and unsafe allowed use of ring circuits instead of radial wiring in houses.
"Encountering one barefoot in the middle of the night will tell you that."
Actually with 3 large prongs in a small area, or a flat back that's really not a major issue even if you are stupid enough to leave them lying around where you will walk in the dark.
"The main reason people think british plugs are safe is because of the built in fuse,"
Mainly it's because a) they ARE much safer as electrocution and electrical fire figures for the UK versus the colonies demonstrate, and b) because of features like the safe high voltage and current handling ability (typically 240 V @ 13A per socket) and the safety shutters on the socket, which together with the insulated live and neutral contacts - means that it's near impossible for kids - or anyone else - to electrocute themselves via UK plugs / sockets.
"but the only reason it NEEDS that fuse"
The reason a UK plug typically has a built in fuse is solely for greater safety. Hence partly why the colonies has an order of magnitude more electrical fires than the UK...
"the stupid and unsafe allowed use of ring circuits instead of radial wiring in houses."
Clearly you have no idea what you are talking about. Ring circuits are used specifically because they have a number of major safety versus cost advantages - such as a single earth continuity failure is unlikely to break the earth for the whole ring, a ring can safely handle far higher loads than a similar cable diameter radial design and can safely support a larger number of sockets, and the BS1363 standard for ring circuits involves far more through safety tests than any equivalent standard in the colonies...
Maybe one that got two year mandatory warranty for the citizen in its Union (and forced Apple to comply as well), or forced MS to open its interoperability APIs, while US agencies decided not to do anything for fear of impacting a US company? Or maybe we should talk about a common connector for chargers (again, something that a US company like Apple try to avoid...)?
Having dealt with many DBAs waiving around the "install guidelines" for Oracle DB and pointing out why unlimited anything is a bad thing (tm) there was never ever a chance of me allowing an Oracle supplied Java installer to run on any machine I owned, regardless of whether its wrapped in a .deb or a .rpm.
I have very little trust in them and absolutely no faith they can get it right. The tar balls and two soft-links are all I've ever needed to get a running Java environment and as it is that easy I keep some of the older tar balls by in case of any compatibility issues.
The best quote about Java was, I think, from Joe Armstrong of Erlang fame. I can't find the psot but it goes along he lines of 'Java was designed for set top boxes. If you are writing a settop box you should be fine'.
I have a long list of issues and problems with Java. My top few are:
1) It tried to be everything to everyone .... and failed, becoming annoying for the majority. If java only had concentrated on a small core of functionality - say a console/text interface, threading, socket-level network stack - with a well-defined interface to allow third party extensions e.g. GUI.
2) Bets the farm on RPC at a time when the short-comings with RPC were well known. Google 'The Game of Distributed Systems Programming. Which Level Are You' - the original blog post has expired! Bet it uses Java!!!
3) To slow to deprecate APIs/features. Java SE has needed en editor and manager. How many GUIs come in the SE distribution? This is connected to 1) - find a good, basic way of doing something and dont muck/mess up the API. Let 3rd parties extend to beyond the core.
4) The language is at the wrong abstraction level. When you need an editor to basicially auto-fill in the syntax fluff you have fsked up the language. Christ, C++14 is less verbose than Java.
5) Licensing Java for 'non-workstation, specialist use' was obscure and appeared to be expensive. Unlike most other people, who bouhgt into th hype, I read the binary license terms and ran away. Yes, there is OpenJDK - 20 years later.
6) They addressed shortcomings by doing more hype, which created more shortcomings, which required more hype. If you are in a hole then stop digging.
7) Its owned and controlled by Oracle. Im out.
Missed one. Java is poor at ongoing updates and maintenance. It appears to be designed by someone who thinks work stops at release 1.0 - that's shipped, out work is done, next!
There was no thought into put into dealing with an application composed of multiple. versioned components/parts. No, the good awful Jar configuration file is not a solution. And its wrote in XML, just to doubly p1ss me off.
'Java was designed for set top boxes. If you are writing a settop box you should be fine'
Java is actually quite poor for STBs; the environment there requires low-level hardware access and reasonably good real-time performance. Thread control is a must.
You could write a STB UI in Java - but that's a small part of the overall problem.
I once went to some Java symposium. The salesman aked me what my target project was, and his face fell when I mentioned set-tops...
Vic.
Oracle were in a catch 22 here. Upgrade the core version and hopefully everything works. Upgrade every crappy version bundled by every crappy little software house and get blamed for breaking everything?
Or does this just apply to RT's listed in the javapath?
I'm not adverse to oracle getting a spanking but there are nuances here.
I would assume it applied to consumers, not enterprise users, who should have tools for managing client installs already, and managing server installs for the main useful and compelling use-case of Java - web application servers.
Given that most consumers probably had Java for Minecraft (and even that now manages JRE installs for the user) and that one BitTorrent client back then, and before that, godawful applets and Yahoo! games.
And let's not even talk about Ask Toolbar bullshite.
Java for consumers is a terrible PITA and Oracle simply haven't helped at all.
1) It was a good idea, badly done, a sort of C syntax Visual Basic for every platform. You really can do a GUI based application that looks like OS native style that runs on all the common desktops. Why though by default do people use the default stupid eye candy builds.
2) The insane license terms for Desktop Java is one reason for Davik etc on Android
3) Sun made a mess of it long before Oracle took over.
4) Amazing how many people don't realise that by default the applications have all the source in a manner easily extracted.
It could be fixed in the future, not impossible even to make a version to rule them all and work with old applications. Better GUI development tools with easier choice of window style etc and distribution only of bytecode.
2) The GUI you talk about came later, only with SWT. First you had AWT, that lead to ugly interfaces, albeit quasi-native. Then there was Swing, with its own design, and thereby, not native and very heavy when machine were not yet enough powerful. And there were also the ugly ones Oracle used in its database utilities...
4) That's a problem with most new languages - including .NET, Python and others. You can still use an obfuscator, but even bytecode can be reversed far more easily than truly compiled code.
Better GUI development tools existed. IIRC Borland JBuilder had one, but you had to pay for it, it wasn't included fully in the free version - and Java contributed to the idea that developer tools should be not paid for, especially because it was often used at school university simply using the javac compiler without an IDE.
Then came Eclipse that reinforced that idea. It should have become the "last IDE", and killed some (including JBuilder), but it wasn't, it was just a cunning IBM way to have people develop an IDE for its expensive solutions, and IBM cared only if it was good enough for them, not if it was really good.
>> The FTC alleged that, in the past, when you installed or updated Java SE, it didn’t replace the version already on your computer.
Well technically, the FTC did indeed "allege" that. But it's rather disingenuous to use that word given that it's 100% true as evidenced by the fact that in the very next sentence Oracle admit to changing that behaviour at a later date!
"Printed on a t-shirt and wearing it whenever I get dragged into a meeting with out oracle sales reptiles."
I'd love to send some sales reps off for a lunch with Mr Creosote.
They get to stretch their expense account with feeding Mr Creosote in return for him ordering everything twice "mixed up in a bucket" which is pretty much what they aim for anyway. Everyone's happy, well at least until sales reps are covered in vomit.
I recall once updating Java on a server, and catastrophically breaking BESx as RIM had bundled the only version of the JRE that worked with BESx with the installer, but hadn't thought to disable update checking in Java or publish anywhere other than on their support forums (when confronted by dozens of angry sysadmins) that BESx would only ever work with the bundled version.
Ended up with 2 parallel JRE installs to get it working again, the alternative being a complete reinstall of BESx.
And there you have your problem.
It's not necessarily the fault of the Java system developers but they have to shoulder part of the blame due to a lack of backwards compatibility. Coders that use Java, however, need to take some of the shit aimed here because of the habit some of them have of demanding that a particular version of Java is used. I can recall having to maintain several versions going back to 1.4.2 to allow for applications that needed that specific version and would refuse everything else.
I suspect, however, that some pressure from developers on Sun/Oracle would have possibly given them cause to consider doing a better job rather than rattling on with the situation as is, only to end up with the Merkan FTC rapping them on the knuckles and sending them to the Naughty Cornertm.
At the end of the day, Java is a language, not an application or a plug in, and every language I have come across, either directly when I still wielded the mighty keyboard of doom or indirectly when I just had to get something to work, has always provided some degree of continuity. Java appears to be an exception to this, hence all this.
And who told the developers to limit the version numbers that the application could run on, because that was what it was tested on, and the company didn't want to accept liability for people running it on a different version?
LAWYERS.
See here, lawyers caused the problem, and who makes money from these lawsuits? Lawyers. Shoot the lot of them, I say.
The other people to blame are the managers and directors in those software companies who don't support their applications in the future to run on more recent versions of the underlying runtime.
in that the latest packages tend to stop older stuff working, so that developers are forced to buy a new subscription and upgrade, This, in order to have the dubious benefit of being able to rewrite/amend their code.
Things have changed with the OS releases though. Here, they give a new edition with tge beneficial features actually turned off, so where most needed most (to counteract low Ram etc on older kit) you getforced to upgrade hardware instead.
"Here, they give a new edition with tge beneficial features actually turned off, so where most needed most (to counteract low Ram etc on older kit) you getforced to upgrade hardware instead."
Tell me about it ... OpenBSD have binned some of the SMD disk support recently... Granted I haven't fired up the old Fujitsu Eagles for a decade now - but still...
You can bet that millions of PCs with older versions of Java are infected and spewing out malware right now. How does forcing Oracle to post a notice that their older Java software is insecure and should be removed eliminate the problem when their new Java software seems to have as many or more security holes as the old stuff?
The problem with new updates clensing older versions is that application require those older versions to work. Wife is an accountant for a large corporation, and this is a constant headache. She's required to use Oracle applications which require a very specific version of Java. Auto updates wiped this version out, and the app wouldn't work with the latest version, so the entire department was down. Offshore admins are absolutely incapable of understanding that some apps may need a version older than "current minus one" so are absolutely no help whatsoever.
So, someone in the department needs to gear up to be an "under the table" IT specialist, tracking Java SE versions on all the department PCs, learning how to turn off auto upgrades, and how to revert to the working edition should offshore force an upgrade.
And mind you, this is Oracle applications trying to work with Java SE, which Oracle also owns. You'd think that if anyone could get that straight, they could.
So yeah, cleaning up all the old versions of Java may sound great from a security perspective, but it will inevitably break mission critical applications. The three parts of security, as I don't need to remind you, are confidentiality, integrity, availability. In practice, the first part is given all the attention to the detriment of the remaining parts.
i have Java installed on my MacPro, and recently after updating to 10.11 from 10.9.5 i have been repeatedly getting a window appearing that says: "To use the "java" command-line tool you need to install a JDK. Click 'More Info' to visit the Java Developer Kit download website."
i click on 'More Info' and it takes me to http://www.java.com/en/download/mac_download.jsp which does not offer me anything other than the latest update to java ... in other words useless ...
i am unsure where to go to next apart from totally uninstalling Java, which will prevent me from using a number of websites that seem to rely on my having Java installed
maybe i should try totally uninstalling, but am getting seriously tempted to just leave it out ... a damn nuisance tho
btw, anyone in the know care to explain why Java programs are so darn fussy about its versions? As far as I know, the language designers and the library are all about using interfaces, to promote flexibility in use. The libraries also seem to keep a lot of old, deprecated, stuff around. Kinda kludgy, but should again promote backward compatibility. The language itself doesn't seem to have undergone massive syntax changes a la Python 2 vs 3. And it seems that sometimes the required version is pretty darn specific, not just a refusal to work on a major release change.
What is driving so many programs to refuse to work with newer versions? Is it Java programmers going out of their way to code version checks? To what purpose? If anything, with Java's security reputation, one would expect developers to want to avoid standing in the way of Java security updates. Are there actual errors happening when one goes up in versions - what type? Is it some "enterprise software" obsession with enforcing that only the certified, tested-upon, version of Java that the software shipped with be used, in order to facilitate vendor support? How do open source Java programs compare then - are they more flexible (without code rewrite)? Do Java, or the VM, somehow have technical flaws that promote backward incompatibility?
Honestly curious.
"Is it some "enterprise software" obsession with enforcing that only the certified, tested-upon, version of Java that the software shipped with be used, in order to facilitate vendor support?"
With the payware I deal with that is usually the case, but there have been cases where jars genuinely have not been forward compatible (deprecated features etc).
I think the root cause behind a lot of the JVM & Java gripes is the idea that Java code should be totally decoupled from the host OS, so you end up with Java app being a square peg being shoved into a round hole. It's the inevitable result of hiding the host OS from the Java devs. :(
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
