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.

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.

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.

>> 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.

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

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.

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

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.

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.

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.

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.