Canonical to remove all Sun JDK packages from the Partner archive(lists.ubuntu.com)
lists.ubuntu.com
Canonical to remove all Sun JDK packages from the Partner archive
https://lists.ubuntu.com/archives/ubuntu-security-announce/2011-December/001528.html
13 comments
I run a Hadoop cluster on Ubunutu and use Sun's JVM. Hadoop doesn't function properly on OpenJDK[1].
"OpenJDK cannot be used to compile hadoop mapreduce code in branch-0.23 and beyond, please use other JDKs."
"OpenJDK cannot be used to compile hadoop mapreduce code in branch-0.23 and beyond, please use other JDKs."
1: http://wiki.apache.org/hadoop/HadoopJavaVersionsyou should migrate to official java distributed by Oracle.
I know, it's stupid. I suppose we can thank Oracle, the non-tech-but-lawyer company for this. Sigh
I know, it's stupid. I suppose we can thank Oracle, the non-tech-but-lawyer company for this. Sigh
The notion of replacing the sun java6 with a openjdk7 is extremely laughable. If you have a high performance java server app, openjdk just doesnt cut it.
Do you have some benchmark results to share?
I would rather say that revoking the packaging license is laughable and sad at the same time
This seems like an good thing, but man is that an awful way of going about this. Forcibly removing the packages during a software update is shady enough, but pushing out blank packages that will cause a user's system to produce issues that the user might not know how to fix, or a reason for the failure?
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.
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.
Since Oracle prevents redistribution of newer versions, there are only three ways we can handle this:
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.
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.
Remove them from the repo, leave them installed, and figure out a better way to inform users of the risk. Some people would find that risk acceptable. Some will take the notification and uninstall or update the software.
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.
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.
If people find having the risk is acceptable, they may use apt pinning to force the older packages to remain installed.
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.
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.
To add to that, once the java plugin is removed the browser will prompt them to install the default (icedtea) which is secure.
They will see the prompt the next time they visit a web page which uses java.
They will see the prompt the next time they visit a web page which uses java.
>> i don't think that's a decision the developers should make for the users
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.
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.
I'm sure there are technical reasons why this isn't being done, but the approach which suggests itself to me is to introduce a dependency from sun-jdk to openjdk, then replace the contents of sun-jdk with symlinks to the corresponding openjdk files wherever possible. Is it feasible to get enough functional this way to make it worthwhile?
While it would mean an easy transition, I'm not sure this is the best way either. As others have noted, I've seen odd cases of things performing extremely poorly or failing in strange ways under OpenJDK 6.
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.
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.
> Remember, if people have Sun's Java installed now, it's because they deliberately opted to install that over OpenJDK
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.
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.
We originally thought about doing that, but we decided not to. It is likely that some users have installed sun-java6 in order to use applications that are incompatible with OpenJDK. If we silently replace sun-java6 with OpenJDK, they may experience unexpected failures or odd behaviour that will be difficult to diagnose.
... and just deleting the version of Java they have installed is somehow more reasonable? Honestly, the fact that this is even being seriously considered by Ubuntu is pretty much a death blow to me ever trusting a package update from the project again... what's next: a security update that uninstalls Apache from my web server, or one that uninstalls Exim from my email server?
Actually, I do think the Ubuntu solution is more reasonable. I installed sun-java6 for precisely the use case mdeslaur described, and I'm pretty sure that the errors from a missing JDK will be much more clear and noticeable than the subtler (but still work-killing) ones from OpenJDK.
So we would be more trustworthy if we left millions of users vulnerable to being silently compromised by malware?
No, Apache and Exim wouldn't get removed, the source is available so a fix can be issued.
No, Apache and Exim wouldn't get removed, the source is available so a fix can be issued.
Strawman. Every other suggestion on this page is more reasonable than the one Ubuntu is choosing, whether it be replacing the package with one that is 90% functionally equivalent (openjdk) to printing giant warnings during the package upgrade process. The decision made by Ubuntu is so uncaring for its user community that this reads like comedy.
Removing packages seems to be the way Linux distros handle this type of issue
https://rhn.redhat.com/errata/RHSA-2011-0368.html https://rhn.redhat.com/errata/RHSA-2008-1045.html
https://rhn.redhat.com/errata/RHSA-2011-0368.html https://rhn.redhat.com/errata/RHSA-2008-1045.html
I disagree. Many people leave windows in favor of Ubuntu for increased security against virus and malware.
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.
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.
Maybe a balance and not remove it on servers? I have a pretty locked down environment and trust my ability to read advisories and take necessary precautions. It's weird to presume your users can't deal with that.
Can it not be done to require explicit confirmation at upgrade-time, the same way a license agreement would? It needn't be silent.
Upgrades are silent and unattended. Tools build on that, sysadmins rely on that.
I think you're making the right decision.
Do those packages that download the file on the user's machine (flashplayer comes to mind) count as redistribution?
We are trying to move away from doing that type of thing, as those packages tend to be fragile and cause a lot of problems for our users.
...and empty packages pretending to be security updates do not cause a lot of problems for people? ;P
Yes?
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.
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.
I don't care about the plugin, nor do I doubt anyone else does: it isn't even being removed, just disabled; additionally, as you say, the user will get a prompt and can easily install it when required, as we are dealing with an interactive GUI. Were I to be in charge of that package, I would easily make that call: it sounds like a great tradeoff.
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.
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.
But as you say, they aren't redistributing the flash files. Those packages are glorified `wget`s hardcoded to point at Adobe's flash releases.
Can you describe any better way that:
- 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.
- 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.
I have one:
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 ?
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 ?
Once the browser plugin gets uninstalled by the package update, visiting a web site that requires a Java plugin will cause the browser to automatically suggest installing OpenJDK/icedtea-plugin.
Multiple times in this discussion thread you have talked about the plugin, but the comment about forcibly removing (as opposed to just disabling) has to do with the JDK, not the plugin. Yes: interactive systems where a user is staring at a web browser designed to download and install plugins is a simple situation to handle. However, servers that are running mail processing backends or websites are entirely different animals.
We are only forcibly removing the plugin for now. Hopefully you will no longer be running your mail servers on an ancient JDK that contains multiple security issues once we do decide to remove it.
Believe me, I would have preferred to simply push out an update to the newest version.
Believe me, I would have preferred to simply push out an update to the newest version.
For the record, I don't use this package at all (I do not currently use Java at all, in fact, although I have extensively in the past while tending sites running on Tomcat). However, all of my servers use Ubuntu, and the idea that removing the JDK is considered a security patch, which normally should "do no harm, add no features, change no behaviors, and only fix bugs", clearly underscores that the Ubuntu upgrade process is not safe.
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.
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.
On the other hand, you don't want thousands of people left with out-of-date versions of the sun JDK. Suppose that a critical vulnerability was found in the last version of the Sun JDK plugin that still had the DLJ? Would you then support removing it in a security update?
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.
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.
How about leaving it installed, not allowing it to be reinstalled, and showing a notification that the software needs to be upgraded manually?
This only works if the person who sees the notification is actually in a position to make a conscious decision on the risk of leaving it installed, and possesses the technical knowledge required to manually install it.
...so we are saying that the person in charge of running security updates on production servers /is/ in a position to make a conscious decision on the (apparently now high) risk of installing what seems like a simple update, and possess the technical knowledge to figure out why suddenly nothing works anymore?...
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).
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).
You can download all the previous versions here:
https://launchpad.net/ubuntu/+source/sun-java6/+publishinghi...
Easy to undo if an insecure version is acceptable to you, and once installed, use apt pinning so it doesn't get upgraded anymore.
https://launchpad.net/ubuntu/+source/sun-java6/+publishinghi...
Easy to undo if an insecure version is acceptable to you, and once installed, use apt pinning so it doesn't get upgraded anymore.
For sake of argument, I just tried to download 6.24-1build0.10.10.1 of sun-java6 for Natty from that website, and the site simply told me it, and all files related to it, were "(deleted)". (Which is so silly and obvious, I have to ask: was this a real suggestion, or are you just trolling me to waste my time checking? ;P)
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?
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?
That means they were deleted from the repository, but they are still archived in launchpad. The reason you don't see the files for 6.24-1build0.10.10.1 is because they were copied over from maverick. If you want the 6.24-1build0.10.10.1 files, you can get them here (click on the architecture you want to download under "Builds" on the top right):
https://launchpad.net/ubuntu/maverick/+source/sun-java6/6.24...
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.
https://launchpad.net/ubuntu/maverick/+source/sun-java6/6.24...
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.
sigh. I go to that URL, and under builds I click "maverick amd64". I then have to select which binary package I want. Let's select "sun-java6-bin 6.24-1build0.10.10.1", as that one will be most critical to someone trying to deal with their JVM disappearing.
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?
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?
Oh, sorry about that, you're right. It appears that the partner archive in Launchpad _does_ actually remove packages after a certain time. My bad.
Considering the steps required to install the Sun JDK in the first place, is it really a stretch to believe these people are able to make a conscious decision about leaving it installed?
An Oracle developer's comment on why the DLJ was retired: http://robilad.livejournal.com/90792.html
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.
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.
Personally I've always had problems with OpenJDK on Ubuntu. Eclipse just doesn't run the same on the OpenJDK as it does on the SunJDK.
It happens to me too and considering my past experience with Eclipse I don't think OpenJDK is to be blamed - I just uninstalled Eclipse and went with IntelliJ IDEA. Works fine.
This is an annoying situation. If Oracle won't allow third-party distribution of the JRE and JDK, they should maintain apt and yum repositories of their own. I'm not sure how they benefit from barring the effort of volunteers who made their software easier to use. I use Sun's JRE because OpenJDK's browser plugin does not work with the management interface of some hardware I use. I'm struggling to find a mailing list I can subscribe to in order to keep up with the updates I'll now have to manually download and install.
Unfortunately, Android development requires the Sun JDK: http://source.android.com/source/initializing.html
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.
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.
I've used OpenJDK to build Gingerbread, and it seemed to work OK, but it wasn't extensively tested. Recently, I'd installed Sun's Java because I wanted minimal hiccups with building ICS. I guess we'll either have to install it manually, or give OpenJDK another try. Ugh. I try so hard these days not to install software manually.
robilad (Dalibor Topic) is the guy who spearheaded the GCJ and Classpath effort that led to Sun's JDK being GPL-ed. I don't know how I feel about him working at Oracle; is he more useful inside or outside?
And thus the first nail in the java coffin. Or at least the Oracle version.
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).
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).
Monetising Java has always been problematic. Linux/GPL people have always been stroppy. Making sure everyone has the latest version is a hard enough problem even without politics.
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.
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.
Your 64bit multicore probably has a 32bit compatability mode, which should be able to execute 386 binaries.
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?
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?
This seems to be an inconvenience for the minuscule number of of Linux desktop users who need Java applets. But Linux server admins won't have a problem installing Oracle Java from Oracle if that's what they need to do.
Remotely deleting stuff on your user's computers reminds me of the Kindle. You just don't do that if you still want people to trust you. Instead, an automatic transition to OpenJDK should be put in place. With this, your java package at least still does java, albeit in a maybe incompatible way.
> You just don't do that if you still want people to trust you.
If you want software you can trust, you shouldn't be using Sun's JDK in the first place.
If you want software you can trust, you shouldn't be using Sun's JDK in the first place.
How in the world does that justify Ubuntu's actions? And this isn't so much about trusting software as it is about trusting an organization.
I'd rather have the old stuff removed in an obvious way rather then have my machine attempt to 'fool' me into thinking that it was still running along as expected, meanwhile I'm hunting for inexplicable bugs and performance penalties introduced by the open JDK. Even worse is to leave it and 'fool' me into thinking the old packages are still being updated only so that I can find out sometime later that my machine is now part of a bot net. Bottom line is removing it and forcing everyone to transition is the most obvious way for users and administrators to deal with what has obviously become a problem. With this news people will have to make a slight change in how they deploy Java apps. it's better to confront them with that choice rather then hide it from them.
Once the browser plugin gets uninstalled by the package update, visiting a web site that requires a Java plugin will cause the browser to automatically suggest installing OpenJDK/icedtea-plugin.
That sounds like good behaviour for the browser plugin, but removing the entire JDK would be annoying if you used Eclipse. I suspect that non-plugin use of the JDK would not be as impacted by the security issues.
And would BREAK things if you run Tomcat/JBoss/Glassfish/etc... Seriously the idea of running a package update that would erase key requirements to running my production J2EE apps is totally insane. I guess I'll stick with RHEL. For all it's issues, they've never talked about silently deleting my JDK.....
redhat also removes packages when they cant update them
https://rhn.redhat.com/errata/RHSA-2011-0368.html
https://rhn.redhat.com/errata/RHSA-2008-1045.html
https://rhn.redhat.com/errata/RHSA-2011-0368.html
https://rhn.redhat.com/errata/RHSA-2008-1045.html
Fortunately, Eclipse users are generally going to be in a position to fix the problem, or they can even pin the packages in advance if they want to remain vulnerable. On the other hand, any other resolution would lead to compromised users not able to fix the problem.
First, if I have my java browser plugin installed, I don't expect my browser to offer me to install my java browser plugin. It may well be a malicious site tricking me into something, who knows.
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.
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.
There is no reason to remove past versions from the archive, since the licence exception allows that. You can still pin or downgrade to that version; I don't think apt-style upgrades should be considered destructive in that sense. The choice was to make upgraded systems secure by default, not to remove options.
So I don't know how Gentoo is currently planning on doing this, but one thing I've noticed with several packages is that if you try and install it, it will exit with a message telling you to go download it from the company however they want you to and stick it in Gentoo's downloaded source directory. (Actually it already does this for the sun-jdk package.) Can't Ubuntu do something similar? Silently removing the package from the repository is one thing and relatively fine; silently removing the actual binaries is another thing and out of the question. That JVM being available may be incredibly important, you have no idea what it's being used for or how susceptible it is to theoretical 0-day JVM vulnerabilities.
Richard Stallman doesn't seem so crazy now, does he?
Oracle isn't demanding Ubuntu actively remove Java from user's computers: Ubuntu has simply decided to do so; they could keep distributing the old version, or even distribute no version at all. Meanwhile, the driving factor behind the license change is "use OpenJDK instead", which would be a step in the right direction with regard to RMS's issues with Java. Oracle is not the problem here: Ubuntu is.
This reminds me of a quote from the movie Analyze This (2002):
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.
Jelly: Anyway, two of the witnesses decided not to
testify and the third guy, well, he commited
suicide.
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.
Yes, I know how to work around this. No, I do think it is reasonable that I might be forced to work around this while I'm in the middle of doing what should have been a routine security upgrade; remember: the original package is gone, and Ubuntu's Java packages have extra supporting material (such as dpkg-alternatives logic) that is missing from Sun's.
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.
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.
It's what everybody else does
see?
https://rhn.redhat.com/errata/RHSA-2011-0368.html
https://rhn.redhat.com/errata/RHSA-2008-1045.html
https://rhn.redhat.com/errata/RHSA-2011-0368.html
https://rhn.redhat.com/errata/RHSA-2008-1045.html
Technical users are the only ones that are going to have this installed. You have to go out of your way to source the partner repo already and then explicitly pick the Sun JDK since it's not the default java implementation. Everyone running the Sun JDK on Ubuntu knows that they're running it.
2011 seems to be the year that has proved Stallman right on so many things.... unfortunately.
Hey, it looks like the garbage collector finally got around to doing its job... :) OK, it's a stretch, but...
(If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell)
(If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell)
Re: Sewell, wouldn't that make Java the inverse of a quine?
To go in the Description field of your bookmark: (quote)
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 [4].
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 [4].
I have to accept not having the latest default JDK on my OSX dev machine... and now my server as well?
"Run anywhere (we want you to)"?
"Run anywhere (we want you to)"?
Redhat's response to the DLJ retirement: https://access.redhat.com/kb/docs/DOC-64765
Basically they have bought a binary code license (BCL) which gets around the problem. Does this apply to Fedora too?
Basically they have bought a binary code license (BCL) which gets around the problem. Does this apply to Fedora too?
[...] so that the Sun JDK will be removed from all
users machines when they do a software update
A ridiculous solution...
Oracle has retired the “Operating System Distributor License for Java”
... to a ridiculous problem.
A ridiculous solution...
Oracle has retired the “Operating System Distributor License for Java”
... to a ridiculous problem.
As a developer who had need to run high performance Java, I gotta say your #1 option is just not an option. OpenJDK with icedtea isn't even remotely close to a replacement.
I understand that Oracle is forcing your hand, but the lack of compassion and sympathy and the ignorant insulting "recommendations" is really off putting.
I understand that Oracle is forcing your hand, but the lack of compassion and sympathy and the ignorant insulting "recommendations" is really off putting.
[deleted]
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 [2]. Sylvestre Ledru suggests [3] 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 [4] 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.