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.

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.

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.

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 ?

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.

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.

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.

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

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.

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?

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.

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?

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?