Last Comment Bug 644682 - New version of JEP (0.9.7.5), please land on branches
: New version of JEP (0.9.7.5), please land on branches
Status: RESOLVED FIXED
: [sg:critical] fixes critical bug 634724
: fixed1.9.0.20
Product: Core
Classification: Components
Component: Plug-ins
: 1.9.2 Branch
: All Mac OS X
: -- critical (vote)
: ---
Assigned To: Steven Michaud
: plugins
:
:
: 634724
  Show dependency treegraph
 
Reported: 2011-03-24 10:56 PDT by Steven Michaud
Modified: 2011-05-24 23:39 PDT (History)
5 users (show)
See Also:
Crash Signature:
  ---
  ---
  ---
  ---
  ---
  ---
  ---
  ---
  ---
  ---
  unaffected
  .17+
  .17-fixed
  .19+
  .19-fixed


Attachments
Change log for JEP 0.9.7.5 (1.65 KB, text/plain)
2011-03-24 10:58 PDT, Steven Michaud
joshmoz: review+
dveditz: approval1.9.2.17+
dveditz: approval1.9.1.19+
dveditz: approval1.9.0.next+
Details

Summon comment box

Description Steven Michaud 2011-03-24 10:56:37 PDT
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.
Comment 1 Steven Michaud 2011-03-24 10:58:04 PDT
Created attachment 521557 [details]
Change log for JEP 0.9.7.5
Comment 2 Smokey Ardisson (offline for a while; no bugmail - do not email) 2011-03-24 11:06:41 PDT
(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 3 Daniel Veditz 2011-03-24 18:17:11 PDT
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
Comment 4 Steven Michaud 2011-03-24 19:06:23 PDT
> 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 5 Daniel Veditz 2011-03-24 23:05:42 PDT
Comment on attachment 521557 [details]
Change log for JEP 0.9.7.5

Approved for 1.9.2.16 and 1.9.1.18, a=dveditz
Approved for 1.9.0.next, a=dveditz
Comment 6 Steven Michaud 2011-03-25 09:31:20 PDT
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.)
Comment 7 Steven Michaud 2011-03-25 09:43:34 PDT
Landed on the 1.9.1 branch:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/51ac17f4dd02
Comment 8 Steven Michaud 2011-03-25 10:01:55 PDT
Just noticed that the a=... numbers in my commit messages are wrong -- they should both be one digit higher.  Bad day, I guess.
Comment 9 Steven Michaud 2011-03-25 10:13:48 PDT
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
Comment 10 Steven Michaud 2011-03-25 13:49:39 PDT
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).
Comment 11 Steven Michaud 2011-03-25 14:08:16 PDT
Marcia and Matt, I'm asking for special attention to Java during QA's
testing of the next two regularly-scheduled branch releases (1.9.2.17
and 1.9.1.19).

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!
Comment 12 Steven Michaud 2011-03-25 14:10:31 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.