Hacker News Reader

Comment by lysium | Hacker News Reader

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.

View on HN

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

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.

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.

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

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.

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.

Reply on news.ycombinator.com