The release of Java update 29 from Oracle marks not only security updates, but a change to the licensing, removing Debian's ability to distribute the non-free JVM. The clause in the Java license under which we were able to distribute Java, the DLJ, has been removed. As a result, the sun-java6 package is no longer suitable for the archive, and has been removed, as documented in Debian Bug #646524 . Sylvestre Ledru suggests  that sun-java6 installs be migrated to openjdk, the open-source alternative, using the following command: "apt-get --purge remove sun-java6-jre && apt-get install openjdk-7-jre" Kai WasserbÃ¤ch has also been pointed out elsewhere  that this upgrade path might not be suitable for all Java programs, and special attention should be paid to re-testing installed Java applications on OpenJDK.
2 : http://bugs.debian.org/646524
3 : http://sylvestre.ledru.info/blog/sylvestre/2011/10/25/removal_of_sun_java6_from_debian
4 : http://www.carbon-project.org/Removal_of_sun_java6_and_ElsterOnline.html
"OpenJDK cannot be used to compile hadoop mapreduce code in branch-0.23 and beyond, please use other JDKs."
I know, it's stupid. I suppose we can thank Oracle, the non-tech-but-lawyer company for this. Sigh
Ubuntu has pretty much always been the "set it and forget it" distro. Problems are often introduced in upgrading to a new release, but once you've installed a release you generally don't get it broken with a routine update. Many people have installed Ubuntu on non-techies' machines in order to not need to do maintenance on them. Unless I'm misunderstanding, all those machines now need to be manually updated to avoid being broken?
I know the blame goes back to Oracle, but Canonical could have handled the issue better. In this case, it seems they're breaking the system to spite Oracle.
1- Leave the insecure packages in the archive, and not update them
2- Remove the insecure packages from the archive, but leave them installed on users' systems
3- Push out an update that removes them from users' systems
Please keep in mind that the security issues present in the old version are currently being exploited by malware on the Internet.
If we do option #1, our users are at risk, and their systems will get compromised.
If we do option #2, new users cannot install the vulnerable packages, but current users get compromised.
If we do option #3, we make sure our users stay secure, at the cost of breaking some installations.
There's no good way of dealing with this, but we are of the opinion that #3 is unfortunately the best way to handle it. If you have a better alternative that we haven't thought of, please let us know. Thanks.
Personally, i don't think that's a decision the developers should make for the users. You don't force them to use your proxy servers or firewalls, why are you taking it upon yourselves to forcibly remove software from their machine without being able to install a newer version? What this update does is fix half a problem and introduce an entirely new one. You can't be the software police.
Our users are expecting that the normal software update process ensures that software they are using is maintained in a secure state with timely security updates. To leave Java at a known vulnerable version would be irresponsible, and most likely not what our users are expecting.
They will see the prompt the next time they visit a web page which uses java.
Seeing the current state of security in many non-updated Windows machines has me disagree with that. Even Microsoft is increasingly changing this kind of 'the users know better' policy in favor of deliberatly securing the system.
Remember, if people have Sun's Java installed now, it's because they deliberately opted to install that over OpenJDK - Sun's has always been in the partner repo, which is disabled by default, OpenJDK being the default on Ubuntu. Silently moving people back to OpenJDK would cause all kinds of non-obvious breakage.
Sort of, the number of "setup ubuntu" or "add codecs to ubuntu" tutorials out that that include replacing openJDK with sun's JVM is very large. While technically people that find such tutorials and blindly copy and paste the commands into their terminal have opted to install Sun's JVM it doesn't mean that they know what they did, why they did it or that it was even necessary.
No, Apache and Exim wouldn't get removed, the source is available so a fix can be issued.
I agree that there could be more transparent feedback to the user who probably will never check to see what's being update and why, but I don't think this reads like comedy at all.
We can assume there are security holes in the current distribution of the Sun JDK plugin, every plugin has some. If there is no way to legally patch them, then the only reasonable response from a security perspective is to remove the package.
In this case there is a mostly acceptable replacement that is easily discoverable (a prompt to install when needed) so it really shouldn't cause any more than temporary inconvenience. Sounds like the right decision in every way.
What I care about is the version of the package that is coming in the "near future" that will entirely remove the JDK from the user's system; the one that is actually "empty", as I specifically stated in my comment you are replying to (and which I can only presume is what the people on this thread that are up in arms about are discussing given the behaviors they are describing).
This package is just going to cause some poor administrator to see "installing 4 security updates" followed by "the server is no longer working", at which point they won't even be able to go "oh shit" and easily fix it, as this e-mail not only claims that the Sun JDK packages will be removed from the partner archives, but (as I was forced to anally demonstrate in another part of this thread) Ubuntu deletes all traces of packages once they are removed from the Partner archive.
The result is that the administrator is going to have the experience of installing a security upgrade, and then having their server non-functional until they can either 1) figure out how to install the SDK from Sun's website in a manner sufficiently compatible with Ubuntu's package (which has a lot of supporting dpkg-alternatives and other configuration behavior) or 2) port their app to work on OpenJDK.
If that isn't enough to drive home the lesson "don't apply security updates without careful review: the people who release them are nigh unto actively trying to mess with you; better to leave it until next week when you have time to test each of the packages to see if they are actually trojans in disguise", a lesson we should very obviously be carefully avoiding teaching /anyone/ (security updates should be something people /always/ are willing to apply), I don't know what is.
- complies with the licensing
- keeps users secure
- will not require additional effort from the user
I can't find one that doesn't involve showing some message and stopping mid-upgrade, which would cause lots of issues for automatic deployment.
1) Display a big bold red message on the user's console or package manager explaining what is happening.
2) Offer to install openJDK as a default action.
3) Profit ?
Believe me, I would have preferred to simply push out an update to the newest version.
I mean, honestly, and you can say "that's stupid, you shouldn't do that, now your argument has jumped the shark", but this policy, if understood by actual users, would simply cause people to never install security updates at all. You want security updates to be a no-brainer: there should never be a downside to installing a security update; you don't want people second-guessing a security update because it might just uninstall the package entirely.
Leaving browser plugins that can't legally be upgraded laying around people's systems is a severe security flaw, so the decision to invasively remove it is definitely the best option.
I mean, this isn't even something they could easily undo: the old packages won't be able to be distributed anymore. They would either have to manually install the SDK themselves in a way compatible with the Ubuntu package distribution, or install OpenJDK and hope for the best (which, as you yourself point out, is unlikely to work, as there is likely a reason they installed the Sun JDK in the first place).
Easy to undo if an insecure version is acceptable to you, and once installed, use apt pinning so it doesn't get upgraded anymore.
Honestly: I have never known Ubuntu to keep an old package around. There was a new update released today, 6.26-2natty1, and the now hours old version 6.26-1natty1 is already marked: "removal requested in 16 hours". Do you have a more serious suggestion for how the old packages could be obtained?
No, I was not trolling you to waste your time.
All old packages are archived in launchpad, even after they get removed from the archive.
At this point, you are presented with the "(deleted)" notice next to the file. In fact, along this path you have been presented with "(deleted)" next to every useful download (such as for sources); the only thing you can get is a 318.5 MiB diff from 6.22-0ubuntu1~10.10.
So no: old packages are /not/ archived in launchpad, and I feel you are just helping prove that. Accordingly, I will now reassert my question re wasting time. Seriously: this is ridiculous; are you even trying these links before claiming they work in specific ways?
I think this won't have a big impact on Java development or use on Ubuntu. Ubuntu's bundled Sun java lagged behind the Oracle official releases, so it wasn't much different from OpenJDK. Disabling the Java browser plugin by default should have always been the sensible option. The plugin has always seemed like an infrequently used security liability.
AIUI, Ubuntu is the primary development platform for Android, (information on the same page), so perhaps Google will produce some kind of solution for this.
Anyone know why Oracle doesn't want people to use java? (and by people I mean linux users and by java I mean their version).
The take home lesson is that getting your language onto every desktop is hard and probably not worth the effort.
Which is sad because the best thing about Java was always how it was OS agnostic. People always used to say about Java "write once, run anywhere"... but that was wrong. It was better than that. It was _compile_ once, run anywhere.
I recently grabbed some of my old (1996) Java code from storage and then ran it on my desktop. The desktop was using a different OS, different chip architecture, everything was different from the machine it was originally compiled on. After 15 years it still ran perfectly.
C is a "write once run anywhere" language, but you have to recompile it for each different platform, which often turns out to be non-trivial. There's no way I could take C code from a Windows 386 machine and run it on a Mac or Linux multi-core 64bit machine over a decade later.
If the native approach does not work, most people use a virtual machine. Does it matter, if the virtual machine is called JVM or VirtualBox?
Java is at best, write once, test everywhere.
If you want software you can trust, you shouldn't be using Sun's JDK in the first place.
Second, this does not solve all the other myriad use cases that do not involve the browser, like stand-alone java programs. What if my java application does not run anymore after switching to a different implementation? I see my java package still installed and 'java' on the command line still works. That's some nice fun cases for "It worked yesterday and I haven't done anything in the meantime" admin calls.
Jelly: Anyway, two of the witnesses decided not to
testify and the third guy, well, he commited
Dr. Ben Sobel: How?
Jelly: He stabbed himself in the back four times
and threw himself off a bridge.
Except that it makes it impossible to do otherwise, as security (a hallmark of desktop Linux) is compromised. Technical users that need to keep their servers up will know how to workaround this, while mom and dad won't care.
Despite the backlash, I think this is the right choice.
It should also be noted/realized that many Ubuntu users even use the "unattended-updates" package that is provided by the distribution, which means that at some point in the middle of the night all of their software is just going to stop working with no notice. Apple isn't even this insane, and people give them all sorts of flak for theoretically having the ability to remotely wipe apps from peoples' phones.
(If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell)
If you are currently using the Oracle Java packages from the partner archive, you have two options:
1- Install the OpenJDK packages that are provided in the main Ubuntu archive. (icedtea6-plugin for the browser plugin, openjdk-6-jdk or openjdk-6-jre for the virtual machine)
2- Manually install Oracle's Java software from their web site .
"Run anywhere (we want you to)"?
Basically they have bought a binary code license (BCL) which gets around the problem. Does this apply to Fedora too?
A ridiculous solution...
Oracle has retired the “Operating System Distributor
License for Java”
... to a ridiculous problem.
I understand that Oracle is forcing your hand, but the lack of compassion and sympathy and the ignorant insulting "recommendations" is really off putting.