Ubuntu disabling the Sun Java JDK browser plugin
| From: | Marc Deslauriers <marc.deslauriers-AT-canonical.com> | |
| To: | ubuntu-security-announce-AT-lists.ubuntu.com | |
| Subject: | Important notice regarding Java packages in Partner archive | |
| Date: | Thu, 15 Dec 2011 14:28:10 -0500 | |
| Message-ID: | <1323977290.2958.16.camel@mdlinux> |
The Canonical partner archive currently contains Oracle's Sun Java JDK packages (sun-java6) for Ubuntu 10.04 LTS, Ubuntu 10.10 and Ubuntu 11.04. As of August 24th 2011, we no longer have permission to redistribute new Java packages as Oracle has retired the "Operating System Distributor License for Java" [1][2]. Oracle has published an advisory about security issues in the version of Java we currently have in the partner archive [3]. Some of these issues are currently being exploited in the wild. Due to the severity of the security risk, Canonical is immediately releasing a security update for the Sun JDK browser plugin which will disable the plugin on all machines. This will mitigate users' risk from malicious websites exploiting the vulnerable version of the Sun JDK. In the near future (exact date TBD), Canonical will remove all Sun JDK packages from the Partner archive. This will be accomplished by pushing empty packages to the archive, so that the Sun JDK will be removed from all users machines when they do a software update. Users of these packages who have not migrated to an alternative solution will experience failures after the package updates have removed Oracle Java from the system. 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]. For more information, please consult the wiki page on the subject [5]. We apologize for any inconvenience this may cause, and thank you for your understanding. [1] - http://jdk-distros.java.net/ [2] - http://robilad.livejournal.com/90792.html [3] - http://www.oracle.com/technetwork/topics/security/javacpu... [4] - http://www.oracle.com/technetwork/java/javase/downloads/i... [5] - https://wiki.ubuntu.com/LucidLynx/ReleaseNotes/Java6Trans... -- ubuntu-security-announce mailing list ubuntu-security-announce@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-security...
Posted Dec 16, 2011 15:52 UTC (Fri)
by ewan (guest, #5533)
[Link] (2 responses)
Whoops.
Posted Dec 16, 2011 16:04 UTC (Fri)
by tajyrink (subscriber, #2750)
[Link]
Note also that OpenJDK already is The supported Java option in Ubuntu, in its main repository, while Sun Java has been hidden in the partner repository which AFAIK isn't even enabled by default.
But yes, fanboys have dissed efforts like gNewSense, and I'd estimate a majority of FLOSS folks in general despite the general interest enjoy the good intentions + 99% approach of Ubuntu. For me as well, I try to use only 100% free software, but I also accept the compromises which help the big user masses when they are so nicely separated. For example I can disable the restricted and multiverse repositories like I always do. But I do also have uttermost respect for gNewSense, Debian etc. license investigation people without which there wouldn't be the level of vigilance for free software in Ubuntu either. (price of the freedom is eternal vigilance...)
Posted Dec 16, 2011 17:08 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link]
Second of all... all the major linux vendors ship some sort of proprietary software in their vendor controlled offerings. RHEL and SLED both distribute proprietary apps to paying customers. I'm pretty sure both RHEL and SLED ship acroread for example (and have to deal with the security issues arising from that in support of customers). So this isn't something particularly different that Canonical is doing.
Let's keep the criticism factual.
Frankly I'm amazed the partner repository continues to exist at all. The business model around it, where vendors would pay Canonical to have their stuff show up there, never really gained traction with enterprise oriented software vendors like it was meant to do. Never more than a handful, and even fewer that lasted from one LTS to the next.
And the new software center approach which encompasses proprietary apps seems to duplicate much of the goals that he partner repository concept was meant to achieve.
-jef
Posted Dec 16, 2011 15:57 UTC (Fri)
by mjw (subscriber, #16740)
[Link]
Posted Dec 16, 2011 16:17 UTC (Fri)
by yodermk (subscriber, #3803)
[Link] (16 responses)
Posted Dec 16, 2011 16:26 UTC (Fri)
by avtechmjc (guest, #50477)
[Link] (3 responses)
Like Sun Java is 100x faster pulling up rows from postgresql in LibreOffice's database app than if OpenJDK is used. But I can't file a bug report, because no one can be expected to replicate my server/client system.
Or accessing fancy encrypted government web sites, where you can't possibly share logins...
It's frustrating when you can't provide useful bug reports!
Posted Dec 16, 2011 16:45 UTC (Fri)
by cesarb (subscriber, #6266)
[Link] (2 responses)
See for instance https://bugzilla.redhat.com/show_bug.cgi?id=741821, where the lack of an empty hidden directory on /etc breaks an online banking applet.
Posted Dec 18, 2011 0:03 UTC (Sun)
by rbrito (guest, #66188)
[Link]
Posted Dec 18, 2011 23:52 UTC (Sun)
by ceplm (subscriber, #41334)
[Link]
Posted Dec 16, 2011 18:45 UTC (Fri)
by andrel (guest, #5166)
[Link]
Posted Dec 17, 2011 5:25 UTC (Sat)
by muwlgr (guest, #35359)
[Link] (10 responses)
Posted Dec 17, 2011 5:43 UTC (Sat)
by muwlgr (guest, #35359)
[Link] (9 responses)
Posted Dec 18, 2011 9:43 UTC (Sun)
by geuder (subscriber, #62854)
[Link] (8 responses)
Now it looks I'm have to change bank (which I should have done anyway because of their incompetent IT strategy), but it has all kind of economical consequences. Or kick Ubuntu / OpenJDK guys even harder. Or just use the one and only PC in the household that is able to dual boot to Windows. 3 not so tempting choices. Sometimes it really sucks to be a Linux guy.
(well there is the 4th choice that the problem has just disappeared by itself in a bit more than a year, need to check again)
(and as I'm whining here a 5th choice comes to my mind, maybe just download OracleJRE from Oracle directly. If I understood the article correctly Canonical does not distribute the new version with security fixes because of some inter-company legal nonsense, which I wouldn't care about)
Posted Dec 18, 2011 11:58 UTC (Sun)
by tkiss80 (guest, #81876)
[Link] (1 responses)
Imagine you have a neighbour who has a contract with a chocolate factory: he gets the chocolate for free, in order to distribute it (e.g. for marketing purposes, it's irrelevant in this example). You get as many as you want from him, and you can be sure it's always fresh and properly packaged (your neighbour takes care of it). What happens when the chocolate factory eliminates the contract? Do you expect your neighbour to steal the chocolate so he can continue distributing? Do you think if you knock harder on his door he will be able to give you chocolate?
Posted Dec 27, 2011 17:14 UTC (Tue)
by steffen780 (guest, #68142)
[Link]
Posted Dec 18, 2011 15:42 UTC (Sun)
by teknohog (guest, #70891)
[Link]
This is how it already works in Gentoo, along with a lot of other proprietary software. You have to download the tarball yourself, but Portage takes care of setting it up.
Posted Dec 18, 2011 16:41 UTC (Sun)
by mjw (subscriber, #16740)
[Link] (2 responses)
You might want to file a bug report upstream against IcedTea-Web if the package maintainer is unresponsive: http://icedtea.classpath.org/bugzilla
Posted Dec 18, 2011 17:50 UTC (Sun)
by gnu_andrew (guest, #49515)
[Link] (1 responses)
Note that the plugin is one of the areas where Sun/Oracle have not released their code as FOSS and, along with the accompanying javaws, the only one not to have any replacement in OpenJDK itself.
Posted Dec 18, 2011 20:24 UTC (Sun)
by geuder (subscriber, #62854)
[Link]
I'll come back to them when I have a bit more time and can overcome my reluctance to address that nasty banking stuff again... I guess chances are still good that I'll do it before migrating to Windows permanently ;)
> A lot of the issues with fixing problems with the plugin and
Absolutely: I have actually contacted my bank last time when I was fighting with the problem and asked them to provide a demo account. Unfortunately without any concrete results. They promised to retun to the issue later, which they haven't done. Some banks here have a demo account just to show how great their pages are. But the guys with the Java stuff don't.
Posted Dec 19, 2011 11:28 UTC (Mon)
by nhippi (subscriber, #34640)
[Link]
Option 8, find other Linux users with same bank and collect a fund to contract someone to fix OpenJDK applet code to work with your online bank.
It may suck to be a Linux guy if you solely depend on goodwill of others. Sure, there is lot of goodwill around, but you can't depend on it. Free software really shines when people scratch their own itches and contribute back the results.
Posted Dec 27, 2011 17:21 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Dec 16, 2011 17:52 UTC (Fri)
by alonz (subscriber, #815)
[Link] (25 responses)
Quoth the article:
>In the near future (exact date TBD), Canonical will remove all Sun JDK
packages from the Partner archive.
The Android build system is officially supported only on Ubuntu 10.04. And it will refuse to work with all but the Sun JDK (in particular: it specifically tests for OpenJDK and refuses to work with it).
So sometime in the near future, many (most?) Android developers will find themselves with hosed build machines. Unless Google (or Canonical) do something first to prevent the meltdown.
Posted Dec 16, 2011 17:59 UTC (Fri)
by dlang (guest, #313)
[Link]
I suspect that google will modify the Android build system to work with openjdk pretty quickly.
Posted Dec 16, 2011 18:48 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (6 responses)
This blog entry has more context:
If you need the Jre 6 binaries still for whatever reason... they are obtainable from Oracle.
-jef
Posted Dec 16, 2011 19:04 UTC (Fri)
by mikov (guest, #33179)
[Link] (5 responses)
No use pretending like this is a harmless unavoidable logical step from Oracle. Removing the DLJ has absolutely no benefit for OS distributors, developers or users and it does cause severe problems for everybody ... except Oracle.
If the "official" JDK is so close to OpenJDK, and if Oracle is providing "gratis" packages anyway, where is the harm in allowing Ubuntu/Debian/etc to package them for everybody's convenience??
I can't help but see as the next step in Java's unavoidable death by the hands of Oracle. Especially if they succeed in killing Dalvik as well.
Posted Dec 16, 2011 19:28 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (4 responses)
It'll be interesting to see what Debian decides to do with the sun-java6-jre package in nonfree which ironically were derived from Canonical's partner repository packages.
And really you shouldn't be too upset that Oracle isn't building debs. Even for those of us who use rpm based distributions, the rpm packages provided by Oracle (and by Sun back in the day) aren't particularly stellar. There's a reason why the jpackage project exists and encourages people to rebuild rpms using their nosrc approach instead of the Sun/Oracle packages to build well formed rpm packages.
And we've already seen examples of Debian doing this sort of workaround when redistribution of the code is not allowed by the license. I'm pretty sure the standard debian and Ubuntu flash-plugin package has historically had to work around a lack of redistribution rights and pull the flash-plugin payload at package install in what is essentially a fake package wrapper that sets up the dependencies correctly and what not. I'm sure a similar deb packaging technical workaround can be found for the oracle jre6 bin if there is enough desire to do it.
-jef
Posted Dec 16, 2011 19:53 UTC (Fri)
by mdeslaur (subscriber, #55004)
[Link] (2 responses)
http://sylvestre.ledru.info/blog/sylvestre/2011/10/25/rem...
Posted Dec 16, 2011 20:20 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link]
Also worth noting the the deb bugreport discussion stresses migration to openjdk instead of trying to support the download packaging hack used by flash plugin package. Seems all the important considerations are all old news.
-jef
Posted Dec 17, 2011 6:25 UTC (Sat)
by pabs (subscriber, #43278)
[Link]
Posted Dec 17, 2011 17:04 UTC (Sat)
by jond (subscriber, #37669)
[Link]
Someone may reintroduce it, or support could be grafted into a generic packaging helper tool such as 'game-data-packer' (which could rename and lose the 'game-' prefix).
Posted Dec 16, 2011 19:22 UTC (Fri)
by tzafrir (subscriber, #11501)
[Link] (6 responses)
In the mean time, which (binary) file needs to be patched to work around this stupid limitation?
Posted Dec 17, 2011 8:43 UTC (Sat)
by geofft (subscriber, #59789)
[Link] (5 responses)
Posted Dec 18, 2011 13:13 UTC (Sun)
by ballombe (subscriber, #9523)
[Link] (4 responses)
Posted Dec 18, 2011 13:48 UTC (Sun)
by khim (subscriber, #9252)
[Link] (3 responses)
Sure. It's actually one single non-technical reason: someone must support different versions and waste time and money better spent on other things. Yesh, right. There are approximately bazillion packages which demand from you "you need pkgtool > 0.9", "please install binutils 2.21 or newer", etc. Why AOSP should be any different? They just check that you use tools which are known to work and don't use tools which are known not to work. I doubt people added this check out of spite: most probably they observed some kind of strange behavior (not necessary "it just refused to build", it may be "some particular rare function started producing incorrect output" or something similar) and instead of trying to fight OpenJDK they just added that check.
Posted Dec 18, 2011 14:09 UTC (Sun)
by raven667 (subscriber, #5198)
[Link] (2 responses)
Posted Dec 18, 2011 18:03 UTC (Sun)
by gnu_andrew (guest, #49515)
[Link] (1 responses)
I can understand the motivation but for those of us working on the code, this kind of thing is quite annoying. It gives OpenJDK a bad press for an issue which may no longer be present and (to my knowledge as IcedTea maintainer and OpenJDK developer) has never been reported.
We do get a number of issues with the javac in OpenJDK 6 because it's some horrible hybrid which has changes that were made for 7 early on (so it's different from the proprietary 6 compiler) but not later fixes (so things that work with 7 don't work with it). On top of that, Oracle, having created this mess, don't seem prepared to support it to a great degree. However, this Android filter also blocks the 7 compiler which should be the same as the one in proprietary versions of 7.
Posted Dec 22, 2011 13:22 UTC (Thu)
by cesarb (subscriber, #6266)
[Link]
It seems they do not want to move to Java 7 because of MacOS:
"We don't want to go again to a situation where we allow two different
JBQ" - http://groups.google.com/group/android-building/msg/bf9d3...
Posted Dec 16, 2011 21:30 UTC (Fri)
by ldo (guest, #40946)
[Link] (6 responses)
Posted Dec 17, 2011 0:26 UTC (Sat)
by alankila (guest, #47141)
[Link] (5 responses)
I think the alleged incompatibility is being exaggerated somewhere.
Posted Dec 17, 2011 17:26 UTC (Sat)
by alankila (guest, #47141)
[Link] (4 responses)
Posted Dec 17, 2011 18:09 UTC (Sat)
by mjw (subscriber, #16740)
[Link] (2 responses)
Posted Dec 17, 2011 19:17 UTC (Sat)
by alankila (guest, #47141)
[Link] (1 responses)
Posted Dec 18, 2011 14:33 UTC (Sun)
by mastro (guest, #72665)
[Link]
Posted Dec 19, 2011 0:48 UTC (Mon)
by mgross (guest, #38112)
[Link]
FWIW I think it craps out in either an SDK or test project. (I don't recall which one was trouble maker)
I recomend folks to get the java from oracle web site and set the shell search path such that the javac used in the build is the one from the oracle JDK install directory and recommend NOT using any distro installed java for building AOSP.
Posted Dec 17, 2011 0:37 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Though I have to admit that I don't use Eclipse integration or anything fancy since I build everything using Maven ( http://code.google.com/p/maven-android-plugin/ ) and IntelliJ IDEA.
Posted Dec 17, 2011 10:16 UTC (Sat)
by alonz (subscriber, #815)
[Link] (1 responses)
Posted Dec 19, 2011 14:30 UTC (Mon)
by jjs (guest, #10315)
[Link]
Posted Dec 21, 2011 17:28 UTC (Wed)
by jrw (subscriber, #69959)
[Link] (14 responses)
This needs to be handled better, from a user's point of view, including:
Perhaps most importantly, it would be nice to have some kind of "OS checkpoint" capability to allow for a rollback if the update fails.
Posted Dec 22, 2011 3:09 UTC (Thu)
by dlang (guest, #313)
[Link] (13 responses)
So Canonical has the options of leaving it in place and having the desktops hacked, or removing it.
the upgrade process doesn't have the ability to do the type of notification that you would like, I'll bet that if you were to dig down into the system to see what was upgraded with the new package, it would tell you exactly what was going to happen and why.
but nobody bothers to read those details.
Posted Dec 22, 2011 3:47 UTC (Thu)
by jrw (subscriber, #69959)
[Link] (11 responses)
After the update broke my java, my research did discover this rationale. However, if I had been given the choice, I would have had no qualms about leaving the active/exploitable security holes in place on my personal desktop, which I keep relatively tight control over, rather than having java removed altogether and losing a critical application.
> So Canonical has the options of leaving it in place and having the desktops hacked, or removing it.
My complaint is with my not being given this choice. Canonical made this choice for me. And consequently broke my system in a way that cost me 3-4 hours to fix at an inconvenient time. Not happy about having to deal with that. Luckily for me, I didn't have an immediate critical need to use Netilla to remote into the servers I am responsible for, or I would have had to drive to the office in the middle of the night.
> the upgrade process doesn't have the ability to do the type of notification that you would like
I'm aware of this, but I'm not happy about it. Using the mechanism they do have available (an upgrade), they deliberately broke my desktop, in a way that had ramifications to me they couldn't possibly have understood. I wrote this post and several others on the ubuntu forums and bugs.launchpad to bring attention to this issue.
> I'll bet that if you were to dig down into the system to see what was upgraded with the new package, it would tell you exactly what was going to happen and why. but nobody bothers to read those details.
If I knew where to find this information, I would read it. If they had provided me a warning, in advance, that I was about to disable part of my system, I would have read it. If they had given me a choice, I would have made the right one for me. For me, a large part of the linux/unix culture is all about choice. I like many things about the way upgrades are handled in Ubuntu, especially how the user is given a meaningful choice about when/if to take an upgrade. But I think they dropped the ball on this one.
Hopefully, Canonical (and other distributions) will improve their tools so that they can offer such a choice in the future. I detailed what I believe is the right way of handling a priori known breakage (give the user an informed, in-your-face, choice). I also noted that some kind of checkpoint system would be very helpful in dealing with updates. I would love to see an auto-checkpoint updating system that allows me to roll back an update. I have had occasion to wish for it several times in the past.
Posted Dec 22, 2011 5:31 UTC (Thu)
by dlang (guest, #313)
[Link] (6 responses)
what tool do you use to do your upgrades? every one of the GUI tools I have seen allows you to look at each package being upgraded and see the description of the package.
> I also noted that some kind of checkpoint system would be very helpful in dealing with updates. I would love to see an auto-checkpoint updating system that allows me to roll back an update. I have had occasion to wish for it several times in the past.
this is something that many people would like to see, but actually implementing it is very hard, and can take a non-trivial amount of storage to do so (and how do you decide how long to keep this?)
If you really want this, run your system on top of LVM and take a snapshot just before you upgrade so that you can revert back to it.
Posted Dec 22, 2011 6:16 UTC (Thu)
by jrw (subscriber, #69959)
[Link] (5 responses)
> what tool do you use to do your upgrades? every one of the GUI tools I have seen allows you to look at each package being upgraded and see the description of the package.
I misread your original comment here. I use Update Manager and I have never found its detailed information useful. In this case I didn't read the detailed information. I browsed through the list of things to be updated, didn't find anything especially interesting in the list of packages, and authorized the update. I didn't find out until I rebooted one or two days later and tried to use Netilla that java had been removed.
What I'm asking for is something in-your-face when there's an expected loss of functionality. When there's a security fix, it should stand out as a danger if you don't accept the update. When there's an expected downgrade, it should stand out as a danger if you do accept the update.
>> I also noted that some kind of checkpoint system would be very helpful in dealing with updates. I would love to see an auto-checkpoint updating system that allows me to roll back an update. I have had occasion to wish for it several times in the past.
> this is something that many people would like to see, but actually implementing it is very hard, and can take a non-trivial amount of storage to do so (and how do you decide how long to keep this?)
I would think that the bulk of what I'm looking for could be achieved by just keeping the previous packages around so they can be reapplied. If a rollback is required, remove the packages that have been added and reapply the packages that have been removed.
> If you really want this, run your system on top of LVM and take a snapshot just before you upgrade so that you can revert back to it.
Perhaps LVM could be helpful here, if the LVM snapshot could be applied to just the OS partitions. Do you know of a How To for using LVM snapshots to rollback OS updates?
Posted Dec 22, 2011 6:57 UTC (Thu)
by dlang (guest, #313)
[Link] (1 responses)
so when you upgrade to GNOME 3 it should warn you that you are about to loose a lot of functionality?
somehow I don't see this taking place.
remember that every upgrade can contain regressions for somebody under some conditions.
Ubuntu does mark some upgrades as being security related. I generally use the command line not the GUI tools, so I can't point you directly at the place to look, but what I remember seeing in passing is that when presented with the list of packages to upgrade, there is a category of security patches.
> I would think that the bulk of what I'm looking for could be achieved by just keeping the previous packages around so they can be reapplied. If a rollback is required, remove the packages that have been added and reapply the packages that have been removed.
you are overestimating the smarts of the packaging tools.
a package contains several pieces, the bulk of the package is the files to install on the system.
However the complicated part of the package are the parts that prepare the system, or change the system as part of the upgrade (frequently modifying config files). These are scripts that can do anything to the system, but these scripts only know about the version of the software that's you are installing (or uninstalling for scripts that make changes when you uninstall a package), they don't know what version used to be on the system, and they cannot possibly know about what changes a newer version may have made to config files to convert them back.
This makes a package based upgrade backout _extremely_ hard to do, and given that a large percentage of upgrade problems have to do with failures of these scripts (not converting config files perfectly), relying on them to be perfect in doing a downgrade is silly.
you may be thinking "well, just make backup copies of the config files then", but this isn't limited to config files, this process can modify _anything_ on your system, databases, files, directories, ANYTHING. This is why installing packages from an unknown source can be so dangerous.
Posted Dec 22, 2011 8:03 UTC (Thu)
by jrw (subscriber, #69959)
[Link]
Also, I'm certainly aware that regressions can happen at any time and there's always some risk when updating. In fact, not so long ago, one of those regressions occurred for me during an upgrade and broke the same application (Netilla). I was not happy about that either, but I believe that it was an accidental regression. It was fixed a few days later.
In this case, the regression was well known (by the package maintainers) in advance, and in fact, the entire reason for the update was to effect a regression! That's what makes this case different and worth discussing.
As to the possibility of restoring previous versions of packages, I believe it would be a welcome step forward if the user could just retrieve and reinstall the exact previous version of the packages he just updated, in the case of a detected regression. That still seems doable in the vast majority of cases. I do understand that in some exceptional cases the changes wrought by a newer package could be so far reaching as to make recovery by reinstallation of the older package unworkable.
I'll have to look into using LVM as a checkpoint mechanism to be able to revert failed updates. But if it can't be scripted up pretty easily, it won't be worth it.
Posted Dec 22, 2011 11:35 UTC (Thu)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Dec 22, 2011 13:33 UTC (Thu)
by jrw (subscriber, #69959)
[Link]
Posted Dec 22, 2011 21:29 UTC (Thu)
by JanC_ (guest, #34940)
[Link]
Posted Dec 22, 2011 5:41 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (3 responses)
Posted Dec 22, 2011 5:58 UTC (Thu)
by jrw (subscriber, #69959)
[Link] (2 responses)
Posted Dec 22, 2011 6:58 UTC (Thu)
by dlang (guest, #313)
[Link] (1 responses)
Posted Dec 22, 2011 7:27 UTC (Thu)
by jrw (subscriber, #69959)
[Link]
As has been pointed out elsewhere, there are packaging techniques which allow for dynamically loading third-party hosted software when the outer package is installed. That may be the only remaining alternative if there's any interest in keeping these packages alive. In my case, I can download and install them manually, so that would only be a small convenience to me.
Posted Jan 27, 2012 19:50 UTC (Fri)
by mfedyk (guest, #55303)
[Link]
Ubuntu disabling the Sun Java JDK browser plugin
Ubuntu disabling the Sun Java JDK browser plugin
Ubuntu disabling the Sun Java JDK browser plugin
Ubuntu disabling the [proprietary] Sun Java JDK browser plugin
Ubuntu disabling the Sun Java JDK browser plugin
Ubuntu disabling the Sun Java JDK browser plugin
Ubuntu disabling the Sun Java JDK browser plugin
Ubuntu disabling the Sun Java JDK browser plugin
Ubuntu disabling the Sun Java JDK browser plugin
Ubuntu disabling the Sun Java JDK browser plugin
Ubuntu disabling the Sun Java JDK browser plugin
Ubuntu disabling the Sun Java JDK browser plugin
May be due to incorporating fix for RH bug 741821
Ubuntu disabling the Sun Java JDK browser plugin
Ubuntu disabling the Sun Java JDK browser plugin
Ubuntu disabling the Sun Java JDK browser plugin
- Physical objects are not AT ALL the same as thoughts/ideas such as software
- Copying software is not the same as stealing an object, since copying doesn't take away the original, whilst stealing an object does.
- Oracle hasn't stopped giving away their JRE, you can still download it free-as-in-free-beer. They're just being assholes to free software for no recognisable purpose, as they do so often.
- The post you replied to never said anything about kicking Ubuntu to get OracleJRE inspite of this being technically illegal - it talked about kicking them to try to track down and fix the bug in OpenJDK
Ubuntu disabling the Sun Java JDK browser plugin
Ubuntu disabling the Sun Java JDK browser plugin
Ubuntu disabling the Sun Java JDK browser plugin
Ubuntu disabling the Sun Java JDK browser plugin
> banking sites has been that we can't reproduce the problem as
> we obviously don't have an account
Ubuntu disabling the Sun Java JDK browser plugin
Ubuntu disabling the Sun Java JDK browser plugin
Uh-oh.Sun JDK & Android AOSP
Sun JDK & Android AOSP
Sun JDK & Android AOSP
http://robilad.livejournal.com/90792.html
Sun JDK & Android AOSP
Sun JDK & Android AOSP
Sun JDK & Android AOSP
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646524
Sun JDK & Android AOSP
Sun JDK & Android AOSP
Sun JDK & Android AOSP
Sun JDK & Android AOSP
Sun JDK & Android AOSP
Sun JDK & Android AOSP
Yes and no...
When software authors are grepping version strings it is always correct to assume they do it for a non-technical reason.
Otherwise they would check for the specific features they need.
Yes and no...
Yes and no...
Yes and no...
versions, like we tried to do with 5 and 6, because the people
building with the newer version when they make changes will break the
build for the people still using the older one. As long as MacOS only
has 6, we'll have to use 6 everywhere.
Sun JDK & Android AOSP
Sun JDK & Android AOSP
Sun JDK & Android AOSP
Sun JDK & Android AOSP
Sun JDK & Android AOSP
Sun JDK & Android AOSP
Sun JDK & Android AOSP
Sun JDK & Android AOSP
The issue isn't the SDK—it's the AOSP release, which has a specific build-time check (in build/core/main.mk) to prevent building with OpenJDK. The check is new to the ICS release, so it's likely that some people haven't seen it yet…
Sun JDK & Android AOSP
Sun JDK & Android AOSP
Downgrade is the new upgrade
- putting the known-downgrade in the user's face before updating
- informing the user of the possible choices
- offering to install a replacement
- allowing an easy way to keep some back-level packages, while updating others.
Downgrade is the new upgrade
> remember that the existing version of java has security holes that are currently being exploited.
Downgrade is the new upgrade
Downgrade is the new upgrade
>> If I knew where to find this information, I would read it.
Downgrade is the new upgrade
Downgrade is the new upgrade
Downgrade is the new upgrade
Downgrade is the new upgrade
What I'm asking for is something in-your-face when there's an expected loss of functionality.
The irony is that text-mode updates have had this for something like ten years, thanks to apt-listchanges' NEWS-file reporting. Graphical package managers don't seem to have caught up.
I'll have to look into scripting a replacement using apt/dpkg. Thanks for the heads up!
Downgrade is the new upgrade
Downgrade is the new upgrade
Downgrade is the new upgrade
I'm not complaining because they put out an update. I'm glad they put out security updates. I'm complaining because their update was a downgrade, and they didn't tell me about it in advance, so I could skip it, and they didn't provide me any way to restore the packages after they had been neutered.
Downgrade is the new upgrade
Downgrade is the new upgrade
Downgrade is the new upgrade
Downgrade is the new upgrade