Closed Bug 644682 Opened 9 years ago Closed 9 years ago

New version of JEP (0.9.7.5), please land on branches

Categories

(Core :: Plug-ins, defect, critical)

1.9.2 Branch
All
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
status2.0 --- unaffected
blocking1.9.2 --- .17+
status1.9.2 --- .17-fixed
blocking1.9.1 --- .19+
status1.9.1 --- .19-fixed

People

(Reporter: smichaud, Assigned: smichaud)

References

Details

(Keywords: fixed1.9.0.20, Whiteboard: [sg:critical] fixes critical bug 634724)

Attachments

(1 file)

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.
blocking1.9.1: --- → .19+
blocking1.9.2: --- → .17+
Version: unspecified → 1.9.2 Branch
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
Attachment #521557 - Flags: approval1.9.2.17?
Attachment #521557 - Flags: approval1.9.1.19?
Attachment #521557 - Flags: approval1.9.0.next?
> 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.
Attachment #521557 - Flags: review?(joshmoz) → review+
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
Attachment #521557 - Flags: approval1.9.2.17?
Attachment #521557 - Flags: approval1.9.2.17+
Attachment #521557 - Flags: approval1.9.1.19?
Attachment #521557 - Flags: approval1.9.1.19+
Attachment #521557 - Flags: approval1.9.0.next?
Attachment #521557 - Flags: approval1.9.0.next+
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.)
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
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
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 (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!
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.
Whiteboard: [sg:critical] fixes critical bug 634724
Group: core-security
You need to log in before you can comment on or make changes to this bug.