Closed Bug 308549 Opened 19 years ago Closed 19 years ago

Apple's OS X 10.3 Java Security Update breaks the Java Embedding Plugin

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: smichaud, Assigned: jaas)

References

Details

(Keywords: fixed1.8)

Attachments

(1 file)

Java console log of this error
1.41 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.11) Gecko/20050728
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.11) Gecko/20050728

Apple's "Java Security Update" for Mac OS X 10.3.X, which was released today,
breaks the Java Embedding Plugin (all versions).  This update was made
available via Software Update at the same time it was released, so many people
may have downloaded it without quite realizing it.

Apple never posted any announcement to their Java-Dev mailing list that they
were working on a Java update for OS X 10.3.X, nor did they post any
prerelease versions to their Developer Connection (to which I belong).

Apple _did_ post pre-release versions of their "Java 1.3.1 and 1.4.2 Release
2" for OS X Tiger (10.4.X), which was also released today.  The Java Embedding
Plugin is compatible with the last pre-release version (DP4), and appears to
also be compatible with the release.

There is no workaround for the problem on OS X 10.3.X.  If possible, please
postpone downloading Apple's Java Security Update until I'm able to release an
update to the Java Embedding Plugin that fixes this problem.  I hope to do
that in the next day or two.

(The Java Embedding Plugin has been bundled with Camino, Firefox and SeaMonkey
nightlies for several weeks, and is also included with Firefox 1.5 Beta 1.)

This report was also posted at:

http://sourceforge.net/tracker/index.php?func=detail&aid=1291312&group_id=107955&atid=649116



Reproducible: Always
> Apple _did_ post pre-release versions of their "Java 1.3.1 and 1.4.2 Release
> 2" for OS X Tiger (10.4.X), which was also released today. The Java
> Embedding Plugin is compatible with the last pre-release version (DP4), and
> appears to also be compatible with the release.

Actually, people using version 0.9.3 or earlier of the Java Embedding Plugin
on Tiger will need (once more) to do the following at a Terminal prompt:

touch "/Library/Internet Plug-Ins/MRJPlugin.plugin"

This is needed to make the MRJPlugin.plugin's date later than that of Apple's
(newly updated) "Java Applet Plugin Enabler".


For the 10.4 folks running nightlies/recent alphas and betas, does the
internally-bundled MRJplugin need to be touched, or is that only for the
stand-alone (/Library/Plug-ins) one?

I'll confirm this to make it easier to find, and cc some folks.
Status: UNCONFIRMED → NEW
Ever confirmed: true
> does the internally-bundled MRJplugin need to be touched

No.

> or is that only for the stand-alone (/Library/Plug-ins) one?

Yes.
Flags: blocking1.8b5?
Do we need to make our browser always load the built-in plugin in preference to
the Library/Plug-Ins one?
> Do we need to make our browser always load the built-in plugin in preference
> to the Library/Plug-Ins one?

Mozilla.org's Mac browsers have always (or at least for a long time) looked
for plugins first in the distro's Contents/MacOS/plugins directory, then in
~/Library/Internet Plug-Ins/, then in /Library/Internet Plug-Ins/.  The plugin
host always takes the first plugin it finds that handles a given MIME type,
and doesn't look any further.  The last modification time (and the "touch"
business) only becomes important if a given directory might contain more than
one plugin that handles a given MIME type.

I believe all this is correct, and shouldn't be changed.  Yes, I suppose that
always grabbing the latest plugin (if it's available) has its merits -- it
would make _this_ problem a little (but only a little) easier to resolve.  But
I think this is trumped by knowing that, if the right stuff (and _only_ the
right stuff) is in Contents/MacOS/plugins, you never have to worry about
version mismatches, or behavior changes from version to version.


Sure, but there's a serious problem lurking here and I want to make sure it
doesn't get swept under the rug.  In a few months' time, we'll cut 1.5/1.0
releases that will be out there in the wild for a long time to come.  It's
evident that it's as easy as pie for Apple to break Java for us.  I have no
doubt that their changes are minor and easily worked around in the JEP itself,
but that won't appease users stuck with a Java-less Firefox 1.5 when Apple
decides to roll another update.  So what do we do?  Cut new releases of the
browsers every time that happens, with fresh JEPs bundled?  What happens to the
folks that don't or won't upgrade?

Now that the JEP lives inside the app package, we've effectively foreclosed
users from installing newer JEPs in local plug-in folders.  The only solution
for is to delve into the app package, and that's beyond the skill sets of many
users.

There's gotta be a better way.

Steven, when incompatibilities like this hit, do they ever require critical
changes to the MRJ plugin?  If the only thing that needs periodic maintenance is
the JEP bundle, then perhaps the MRJ plugin could be modified to use the newest
JEP it can find.  I'd understand if that might put you in an uncomfortably tight
spot with APIs, though.

Maybe we should always go for the most recent plugin, even if MRJ has to be
treated as a special case.

Or maybe we should just provide and document a way to turn the MRJ off without
killing plugins altogether, letting the user force a fallback to Java 1.3 in the
event that an incompatibility such as this one crops up again.
I think there's only one good solution to this dilemma -- "we" have to
convince Apple not to do this again with a minor update (major updates, like
from Mac OS X 10.3.X to 10.4.X are a different matter).

I don't think Apple did this deliberately.  Rather, they just didn't (and
don't) test with the Java Embedding Plugin.  (And, because they didn't give
any pre-releases to Developer Connection members, they didn't give _me_ a
chance to test, either.)

By myself, I'm just a minor player.  But once the Java Embedding Plugin is
included in (especially) Firefox, it's no longer in the same situation.  I
can't believe that Apple didn't test with recent released versions of Firefox
(at least).  I think "we" ... that is _you_ :-) ... need to convince Apple to
add Firefox-plus-the-JEP (and maybe Camino-plus-the-JEP) to their test bed.

(Once I've had a night's rest I'll say more about what we might do about this
particular problem, now that it's happened.)


we know someone on the Java team (chris mcafee) who used to be fairly involved
with having them do the right thing for us. we should try to poke him and see
what happened this time around. anyone have his contact info?
Chris McAfee wrote me a while ago offering his help to test universal binaries
of the Java Embedding Plugin.  (I've been so busy with other things that I've
had to put that off.)  His position at Apple is "Java Release Engineer" ... so
it sounds like he'd be just the right person to contact.

I'll send you his email addresses (I have two of them) in private email.
(Feel free to pass them around to others in mozilla.org.)  It's probably
alright for me to mention them here ... but just in case.

Once things have quited down a bit (after I've released my new version), I'll
write him myself, too.

And once that new version is out (today or tomorrow), I'll have time for a
detailed discussion, here, of what to do about this problem, and other
problems with embedded copies of the Java Embedding Plugin that might arise in
the future.
Flags: blocking1.8b5? → blocking1.8b5+
I've just released JEP 0.9.4, which fixes this problem.

http://javaplugin.sourceforge.net/

> And once that new version is out (today or tomorrow), I'll have time for a
> detailed discussion, here, of what to do about this problem, and other
> problems with embedded copies of the Java Embedding Plugin that might arise
> in the future.

Let's hold this off until tomorrow, at least.  I need a break :-)


I apologize for the non-heads-up about the 10.3 update, we were not allowed to preview anything.

I have suggested to my group that we add JPE/Firefox to our internal testing suite, I agree
it would be good not-to-break-this next time.

I can continue some of this discussion in email, please send me email.
I think the best way to get JEP 0.9.4 to users of Firefox 1.5 Beta 1 and
Camino 1.0 Alpha 1 is to land it on the trunk and the 1.8 and Camino-1.0
branches as soon as possible.  Then users of these two distros who are running
on OS X 10.3.X can be told to download the appropriate nightly.

But I'm afraid 0.9.4 has some problems (though nothing severe), so I'm going
to follow it pretty soon (sometime next week) with a 0.9.4+a "nightly".

I've discovered a couple of occasional-crash bugs that (I think) are new since
0.9.3.  I missed them in my rush to get 0.9.4 out the door.

(There's also what I think might be a Camino bug (trunk and 1.0 builds only),
which also happens with 0.9.3 and which I missed earlier -- Camino tends to
crash (in mozilla.org browser code) when you quit it while a browser page is
open that contains lots of applets.  If possible, I'd also like to include a
fix/workaround for this in 0.9.4+a.)

Once 0.9.4+a is out, it, too should (I think) get onto the trunk and 1.8 and
Camino-1.0 branches as soon as possible -- the better to test it and find
whatever problem _it_ may have.

(Ordinary Firefox users will, I think, find it equally difficult to install a
new JEP to /Library/Internet Plug-Ins/ or to their distro's
Contents/MacOS/plugins.  So asking them to do either of these things is a
non-starter.)
Here's an idea that should probably get its own bug, if it's at all feasible.
But I'll mention it first here where a lot of the mozilla.org principals will
see it:

Is there any chance that the mechanism used (in Firefox) to install extensions
could be used to install JEP updates to the distro's Contents/MacOS/plugins
directory?


Steven: you can see the reported crashes for 1.0a1 here:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=&vendor=All&product=Camino10&platform=All&buildid=2005091409&sdate=&stime=&edate=&etime=&sortby=bbid

Note that some are known bugs that have been fixed on the trunk (all the
JS_DHashTableOperate ones), but I've seen at least one that looks like a JEP issue.
> but I've seen at least one that looks like a JEP issue

The ones in libhotspot.dylib (there are four of them) seem likely candidates.
Of those, two are due to the incompatibility with Apple's Java Security Update
(the ones with the crash in Class_getMethods0()_redirect()).  The other two
seem related to each other ... but who knows?

I really, really, really wish Talkback was able to collect stack traces (at
least on Mac OS X) -- without them its incident reports are _much_ less
useful.


> I really, really, really wish Talkback was able to collect stack traces (at
> least on Mac OS X) -- without them its incident reports are _much_ less
> useful.

I mean traces for _all_ the threads, as OS X gives you.


talkback should submit crashreporter logs, I wonder if it could be changed to do that.

CC me on libhotspot crashes, I can see if they reproduce for us.

Firefox should bundle this plugin, that would help our internal testing quite a bit.
Users are going to want a 1.4.2 experience instead of a 1.3.1 one, I think the download size/
functionality tradeoff is worth the extra size here.
> CC me on libhotspot crashes, I can see if they reproduce for us.

The two "unknowns" are TB9372728 and TB9372670.  If you can find a way to
reproduce them, please open a bug (either here at bmo or using the JEP's Bugs
tracker).  If you do it here, be sure to put me on the CC list :-)


> two are due to the incompatibility with Apple's Java Security Update
> (the ones with the crash in Class_getMethods0()_redirect())

This is incorrect ... I spaced it out.

So, Chris, here are two more to add to the list that you're checking:

http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=9427363
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=9407018

Thanks in advance!

Java_java_lang_Class_getMethods0_redirect() is actually in
MRJPlugin.plugin (in MRJSession.cpp), not in libhotspot.dylib.  It's
part of a fix for a minor security hole in LiveConnect that I reported
to Sun and Apple on 2005-03-07.  The Apple "radar" is 4040240.  Sun's
bug id is 6248410 (which isn't publicly accessible, since this is a
security issue, but which Apple no doubt can get access to).

My fix appeared in JEP 0.9.2 (released 2005-05-18).


> My fix appeared in JEP 0.9.2 (released 2005-05-18).

I'll eventually get this right :-(

My fix appeared in JEP JEP 0.9.1 (released 2005-05-09).


For the record, here's what happens to someone experiencing this bug:

No Java applets work (loading them appears to do nothing), but the
browser continues to function (otherwise) normally.

I've attached a log of the error messages you get in the Java Console.
for reference, this would have worked:
Incident ID: 9372728 
Incident ID: 9372670
*** Bug 309497 has been marked as a duplicate of this bug. ***
'll repeat my question from comment #13 above:

Is there any chance that the mechanism used (in Firefox) to install extensions
could be used to install JEP updates to the distro's Contents/MacOS/plugins
directory?


Maybe Ben can answer that.
We can use the normal software update system which firefox has these days;
though, it requiers a version bump anyway, not all that good.
So what do we do here?  Is 0.9.4 a viable replacement for 0.9.3 at this point? 
Does it introduce any new problems?

Other concerns, like distributing JEP updates, should get their own bugs.
The update to 0.9.4 (on the trunk and branches) has now waited so long that
I'd say you should just wait a bit longer, for 0.9.4+a.

I'm working on it as we speak.  It fixes a number of fairly significant
issues, which it turns out were nearly all old issues (i.e. not introduced by
0.9.4) ... and mostly (though not entirely) workarounds for Apple bugs :-)

(One issue that I'm glad I _didn't_ have to deal with is
Camino-crashing-on-exit-with-lots-of-applets (comment #12).  This seems to
have gotten fixed on both the trunk and the branches.  It may also have
effected Firefox, though less severely.)

I hope to release 0.9.4+a in the next couple of days.

> Other concerns, like distributing JEP updates, should get their own bugs.

I will open a new bug to deal with my question in comment #13 and comment #25,
and CC everyone here.


> I will open a new bug to deal with my question in comment #13 and
> comment #25, and CC everyone here.

Done.  It's bug 309636.


->josh
Assignee: nobody → joshmoz
Steven: Tuesday is the branch lockdown, and drivers would like a new JEP (0.9.4
or newer) on the branch by then if possible. Since we're getting down to the
line, do you plan on having a new version done and stable enough by then or
should we land 0.9.4 on Monday?
I should be able to release 0.9.4+a tomorrow, if all goes well.

That should be landed on the trunk and both branches.

And I think future versions (even future "nightlies") should be landed on the
trunk and both branches as soon as they're released.  That gives them much
greater exposure, and increases the chance that bugs will be found and fixed
before an actual "release" (alpha or beta or whatever) takes place.


> I should be able to release 0.9.4+a tomorrow, if all goes well.

I'm not going to be able to release 0.9.4+a today -- one of the things I
thought I'd fixed turned out not to be.

But that issue's now cleared up, and other tests have gone well.  I should be
able to make tomorrow (Saturday, 9-24).  I'll post another note here as soon
as it's done.


I've just released version 0.9.4+a of the Java Embedding Plugin.  You can
download it from http://javaplugin.sourceforge.net/.

> I've just released version 0.9.4+a of the Java Embedding Plugin.  You can
> download it from http://javaplugin.sourceforge.net/.

Please land it on the trunk and the 1.8 and (Camino) 1.0 branches as soon as
possible.


> Steven:  Tuesday is the branch lockdown, and drivers would like a new JEP
> (0.9.4 or newer) on the branch by then if possible. Since we're getting down
> to the line, do you plan on having a new version done and stable enough by
> then or should we land 0.9.4 on Monday?

> I've just released version 0.9.4+a of the Java Embedding Plugin.  You can
> download it from http://javaplugin.sourceforge.net/.

> Please land it on the trunk and the 1.8 and (Camino) 1.0 branches as soon as
> possible.

Well? :-)


Is it _next_ Monday or Tuesday that's the branch lockdown?  I hope so :-)

> Upcoming milestones:
>
> Sept 6: Lockdown for 1.5b1
> Sept 8: Release 1.5b1
> Oct 3: Lockdown for 1.5b2 <------------
> Oct 5: Release 1.5b2
> Oct 26: Lockdown for 1.5RC1
> Oct 28: Release 1.5RC1

(http://developer.mozilla.org/devnews/index.php/2005/08/30/9-days-untill-15-beta/)


JEP 0.9.4+a landed on branch and trunk.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
> JEP 0.9.4+a landed on branch and trunk.

Thanks!
Keywords: fixed1.8
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: