Closed Bug 644682 Opened 9 years ago Closed 9 years ago
New version of JEP (0
.9 .7 .5), please land on branches
JEP 0.9.7.5 fixes a major security hole (bug 634724), and also works around some breakage caused by Apple's latest Java updates (Update 4 for OS X 10.6 and Update 9 for OS X 10.5). One of these Apple-triggered problems is itself a major bug -- as of Apple's latest updates, older versions of the JEP now leak all Java applets (they don't get destroyed when the plugin is unloaded). Because I don't want to reveal too much about the security bug before it's been fixed in all current Mozilla releases, I haven't yet formally released JEP 0.9.7.5 (I haven't yet uploaded it to http://javaplugin.sourceforge.net/). That's also why I've marked this bug security sensitive. I'll email copies of the JEP 0.9.7.5 distro to Josh (who I'm going to ask to review), and to anyone else who wants one. It's about 4MB. JEP 0.9.7.5 needs to be landed on the current branches today, to make the code freeze for FF 3.6.17 and 3.5.19. Sorry I've cut it so close, but I had little choice. Fixing bug 634724 took much longer than expected, and I also didn't expect to have to deal with Apple's breakage. It should probably also be landed on the 1.9.0 branch, so Camino can pick it up. Those who want to try the new version right away will need to install it "over" the older versions currently bundled with Mozilla.org browsers. I recommend doing the following. Note that these instructions have changed from what I used to recommend. This is because Apple made changes in their most recent Java Updates (on OS X 10.5.X and 10.6.X) that cause the previous instructions to no longer work properly. For each of the browser binaries you wish to update: 1) Control-click (or right-click) on the browser binary and choose "Show Package Contents". 2) Browse to the Contents/MacOS/plugins folder and delete JavaEmbeddingPlugin.bundle and MRJPlugin.plugin. 3) Drag copies of the new Java Embedding Plugin binaries to the Contents/MacOS/plugins folder.
Assignee: nobody → smichaud
Status: NEW → ASSIGNED
Attachment #521557 - Flags: review?(joshmoz)
(In reply to comment #0) > It should probably also be landed on the 1.9.0 branch, so Camino can > pick it up. Steven, can you mail me (at this address) a copy for some quick testing, since this new version is not yet available publicly? And, yes, we do want this to land on 1.9.0 for the hopefully-final Camino 2.0.8 release.
Comment on attachment 521557 [details] Change log for JEP 0.9.7.5 >2. Work around changes in Apple's latest Java updates that cause > previous versions of the Java Embedding Plugin to leak all Java > applets. Does the new JEP still work on machines that have _not_ been upgraded with the latest Apple Java update? Requesting (not granting) approval to make sure it shows up in release bug queries. Waiting for Josh's review for approval
> Does the new JEP still work on machines that have _not_ been upgraded with the > latest Apple Java update? Yes. I always maintain backwards compatibility with previous Java updates.
Comment on attachment 521557 [details] Change log for JEP 0.9.7.5 Approved for 126.96.36.199 and 188.8.131.52, a=dveditz Approved for 1.9.0.next, a=dveditz
Landed on the 1.9.2 branch: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/fd2bd9ee3f7b (Oops, forgot to mention the bug number in my commit message.)
Landed on the 1.9.1 branch: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/51ac17f4dd02
Just noticed that the a=... numbers in my commit messages are wrong -- they should both be one digit higher. Bad day, I guess.
Landed on the 1.9.0 branch: Checking in JavaEmbeddingPlugin.bundle/Contents/Info.plist; /cvsroot/mozilla/plugin/oji/JEP/JavaEmbeddingPlugin.bundle/Contents/Info.plist,v <-- Info.plist new revision: 1.24; previous revision: 1.23 done Checking in JavaEmbeddingPlugin.bundle/Contents/MacOS/JavaEmbeddingPlugin; /cvsroot/mozilla/plugin/oji/JEP/JavaEmbeddingPlugin.bundle/Contents/MacOS/JavaEmbeddingPlugin,v <-- JavaEmbeddingPlugin new revision: 1.25; previous revision: 1.24 done Checking in JavaEmbeddingPlugin.bundle/Contents/Resources/English.lproj/InfoPlist.strings; /cvsroot/mozilla/plugin/oji/JEP/JavaEmbeddingPlugin.bundle/Contents/Resources/English.lproj/InfoPlist.strings,v <-- InfoPlist.strings new revision: 1.24; previous revision: 1.23 done Checking in JavaEmbeddingPlugin.bundle/Contents/Resources/Java/JavaEmbeddingPlugin.jar; /cvsroot/mozilla/plugin/oji/JEP/JavaEmbeddingPlugin.bundle/Contents/Resources/Java/JavaEmbeddingPlugin.jar,v <-- JavaEmbeddingPlugin.jar new revision: 1.24; previous revision: 1.23 done Checking in MRJPlugin.plugin/Contents/Info.plist; /cvsroot/mozilla/plugin/oji/JEP/MRJPlugin.plugin/Contents/Info.plist,v <-- Info.plist new revision: 1.24; previous revision: 1.23 done Checking in MRJPlugin.plugin/Contents/MacOS/MRJPlugin; /cvsroot/mozilla/plugin/oji/JEP/MRJPlugin.plugin/Contents/MacOS/MRJPlugin,v <-- MRJPlugin new revision: 1.25; previous revision: 1.24 done Checking in MRJPlugin.plugin/Contents/MacOS/MRJPlugin.jar; /cvsroot/mozilla/plugin/oji/JEP/MRJPlugin.plugin/Contents/MacOS/MRJPlugin.jar,v <-- MRJPlugin.jar new revision: 1.24; previous revision: 1.23 done Checking in MRJPlugin.plugin/Contents/Resources/MRJPlugin.rsrc; /cvsroot/mozilla/plugin/oji/JEP/MRJPlugin.plugin/Contents/Resources/MRJPlugin.rsrc,v <-- MRJPlugin.rsrc new revision: 1.20; previous revision: 1.19 done Checking in MRJPlugin.plugin/Contents/Resources/English.lproj/InfoPlist.strings; /cvsroot/mozilla/plugin/oji/JEP/MRJPlugin.plugin/Contents/Resources/English.lproj/InfoPlist.strings,v <-- InfoPlist.strings new revision: 1.24; previous revision: 1.23 done
I've released JEP 0.9.7.5 to the public at http://javaplugin.sourceforge.net/. Starting with JEP 0.9.7.4, I began postponing the formal release of JEP versions that included fixes for security bugs. The idea was to reveal as little information as possible about these bugs until fixes had gotten into current releases of Mozilla browsers, and users had been given a chance to upgrade. My intention was to do Mozilla and Mozilla users a favor. But this favor went (mostly) unnoticed for months, and then caused considerable displeasure at the last possible minute before the next round of branch releases. Which (in some people's minds) made me appear to be reluctant to release JEP source -- which is the very last thing I want. So from now on I'm going to formally release every new version of the JEP before I ask for it to be landed in the tree, even if it contains security fixes. My change of policy is partly due to the bad feeling all this has caused. But mostly it's because I now think I was being too cautious. In most cases (and certainly for the two security bugs fixed in JEP 0.9.7.4 and 0.9.7.5), seeing how a security bug was fixed doesn't tell you how to exploit it. You need to be a bit cagey about what you say in your code comments and change logs. But I *have* been -- for example I never described the exploits directly, but instead pointed people to bmo bugs where they were described (which can be kept restricted until the danger has passed). It's conceivable someone could discover a security hole so obvious that its fix would reveal how to exploit it. If this happens I'd be willing to make an exception. But I think it's extremely unlikely. It helps that the JEP has had very few security holes -- only two since it started being bundled with Mozilla browsers. And of these only the latest one was really the JEP's fault (or more properly the fault of the MRJ Plugin Carbon code inherited by the JEP).
Marcia and Matt, I'm asking for special attention to Java during QA's testing of the next two regularly-scheduled branch releases (184.108.40.206 and 220.127.116.11). As always, I've been quite thorough in my own testing. But because bug 634724 was much harder to fix than I expected (and because I took considerable time out to work on Mozilla bugs), JEP 0.9.7.5 will only be on the branches for a very short time before it goes out in releases. So it'll get less user testing than normal. Probably the best resource for Java testing is the information at bug 371084. If you guys need any help, I'd be more than happy to provide it. Thanks in advance!
In light of what I said in comment #10, I don't think this bug needs to be security-sensitive. If I hear no objections, I'll uncheck the box early next week.
You need to log in before you can comment on or make changes to this bug.