Closed Bug 293973 (JEP/caps) Opened 19 years ago Closed 10 years ago

Metabug to follow CAPS changes relevant to the Java Embedding Plugin

Categories

(Core :: Security: CAPS, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: smichaud, Assigned: dveditz)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050511
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050511

Four different IIDs/uuids have been in use for
nsIScriptSecurityManager at various times among the Mozilla family of
browsers since 2004-01-01.  Two different ones remain in use currently
-- one on the Mozilla 1.7 and Aviary branches, and a different one on
the trunk.

Wouldn't it be nice to have just one?  Will getting there involve a
few dozen more intermediate changes?

I'm the author of the Java Embedding Plugin
(http://javaplugin.sourceforge.net/), and I bumped up against some of
this complexity when Firefox 1.0 broke the MRJ Plugin Carbon (a
cleaned-up version of which is part of my Java Embedding Plugin
distro) -- https://bugzilla.mozilla.org/show_bug.cgi?id=234169#c75.  I
worked around that and continued on my way.

Just now I found out that the MRJ Plugin continues to be broken in all
the browser nighlies -- all those based on the trunk and released
since 4-25-2004.  The break wasn't immediately obvious (otherwise I'd
have noticed it sooner).  And fortunately it only effects the
nightlies, alphas and betas (none of the released versions).  But it's
still a pain to have to deal with ... which I'll have to do in my next
release.

Here's a timeline of these four different IIDs:

Up until 2004-04-25, there seems to have been just one:

    uuid(58df5780-8006-11d2-bd91-00805f8ae3f4)

On that date it was changed on the trunk (though not on any of the
branches) to:

    uuid(82bff35d-ebb7-4cb9-bb47-4f9ebdf11f77)

On 2004-10-24 it was changed on the Aviary branch from the ancestral
one (58df5780...) to the following (this was the change that broke the
MRJ Plugin when it appeared without warning in Firefox 1.0):

    uuid(18158378-b632-436a-9ced-c52ded350bde)

On 2004-12-03 it was changed on the Mozilla 1.7 branch from the
ancestral one to the one already in use on the Aviary branch
(18158378...).

On 2005-02-02 it was changed on the trunk from 82bff35d... to the
following:

    uuid(463eb1fa-9dac-4ca7-826f-1fc921971d3a)

Yes, I know that the caps interfaces aren't yet frozen.  But you have
no choice but to use them if you want to do certain things -- as has
the MRJ Plugin Carbon, which is/was an official Mozilla.org release
(http://www.mozilla.org/oji/MRJPluginCarbon.html).



Reproducible: Always
Summary: Will nsIScriptSecurityManager's IID ever stop changing? → Metabug to follow CAPS changes relevant to the Java Embedding Plugin
The change on the trunk (on 2004-04-25) to
uuid(82bff35d-ebb7-4cb9-bb47-4f9ebdf11f77) coincides with (and was
made necessary by) the addition of the checkLoadURIWithPrincipal()
method.

The change on the trunk (on 2005-02-02) to
uuid(463eb1fa-9dac-4ca7-826f-1fc921971d3a) coincides with (and was
made necessary by) a change to the checkLoadURIStr() method.

(Following up comment #0)

> Just now I found out that the MRJ Plugin continues to be broken in
> all the browser nighlies -- all those based on the trunk and
> released since 4-25-2004.

I've now fixed this problem in JEP 0.9.2, just released.  And since
there is now a fix, I can be less coy about the nature of the problem
-- it was a big security hole.  For more information see:

http://javaplugin.sourceforge.net/
http://javaplugin.sourceforge.net/nsIScriptSecurityManagerVuln.html

CC'ing people thinking about changing caps interfaces yet again.
Status: UNCONFIRMED → NEW
Ever confirmed: true
So... The caps interfaces are in terrible shape, really. We have several bugs on
file on the interfaces ranging from "interface very misleading" to "interface
unusable for the purpose it purports to be usable for".

Perhaps we should take a careful look at this stuff and actually freeze a subset
of the interfaces for 1.8 or something?  Steven, could you indicate which parts
of the interface you see as absolutely indispensable?

That said, changing the iid if the interface changes is a must to prevent
crashes, so if we do change these at all we do have to change the iid...
you should be thankful that the IID actually changed. that allows you to be
compatible with all versions in the same binary! ;)

(by getting the IDL files for all the IIDs, renaming them so they don't
conflict, compiling each to a header, and try to QI to each of the interfaces in
turn until you succeed; or if you implement it, by implementing all the interfaces)
The CAPS interfaces are nsIPrincipal, nsIScriptSecurityManager,
nsISecurityCheckedComponent and nsISignatureVerifier, right?  (As
embodied in the four *.idl files in the mozilla/caps/idl directory.)

The MRJ Plugin JEP currently uses the following (and needs to continue
using them):

It uses the nsIScriptSecurityManager contract id
("@mozilla.org/scriptsecuritymanager;1", which as far as I know has
never changed) to get a pointer to the nsIScriptSecurityManager from
the nsIServiceManager interface.

It calls GetSubjectPrincipal() on the nsIScriptSecurityManager
interface pointer to get a pointer to the nsIPrincipal interface (this
happens in CSecureEnv::sendMessageToJava()).

It calls GetOrigin() on the nsIPrincipal interface pointer (this
happens in GetLiveConnectProxy() in CSecureEnv.cpp).

(There's also some currently unused (commented out) code in
newCodebasePrincipal() in LiveConnectNativeMethods.cpp. to get an
nsICapsManager interface pointer and call CreateCodebasePrincipal() on
it.  But this appears to be obsolete (it seems to have been replaced
by nsIScriptSecurityManager::GetCodebasePrincipal()), and in any case
I don't forsee the need to use it.)

Yes, I'm grateful the IIDs were changed when the other changes were
made, and I realize things would have been even worse if they hadn't
been.  All I ask is that the people in charge of the CAPS interfaces
have some idea who's using them, and try to take their "consumers"
into account when they make changes.  We now all seem to be on the
same page on that issue ... for which I'm even _more_ grateful :-)

Finally, just to reiterate from comment #2 above:  I've accomodated
all the changes that have been made up to the present date (... unless
there are _still_ some other things I've overlooked).  My current
concern is to make sure I keep up with _future_ changes.

Steven, you might be interested in bug 240661...
> Steven, you might be interested in bug 240661...

Thanks for pointing this out to me.  I've added myself to that bug's
CC list.

I looked through your latest patch (though I haven't compiled or
tested it yet).  The new nsIScriptSecurityManger IID will (of course)
require a change to the MRJ Plugin JEP.  And so might the changes to
the nsIPrincipal interface, if they end up changing GetOrigin()'s
position in the nsIPrincipal vtable.

I have no objection to these changes, or to similar ones that I know
about far enough in advance to not severely disrupt the JEP's release
schedule (such as it is), and which appear in nightlies at least a few
weeks before they appear in a "release" (even an alpha or beta).
(Assuming, of course, that you don't remove the functionality I talked
about in my comment #6.)  If, for a few weeks, LiveConnect is broken
on the most recent nightlies, people can learn to live with it --
someone who uses a nightly is by definition not a naive user.

It's true that, in an emergency, you might have to do a quick change
to a released version that breaks the JEP (for example to close a
major security hole) ... but something like that would upset
_everyone's_ release schedule, not just the JEP's.

As best I can tell, I'm a few weeks away from releasing JEP 0.9.3.
When I get within a week of my next release, I'll compile the latest
version of the bug 240661 patch and alter the MRJ Plugin JEP to be
able to work with it.

Just make sure the patch is ok with the security people before you do that, I
guess.  I'm fully expecting them to start debating the api changes... ;)
Marking the dependency to link the bugs
Depends on: 240661
Depends on: 292368
nsIPrincipal's iid just changed again -- bug 300008
Depends on: 300008
Thanks for letting me know!

Bug 300008 is still restricted, but I can see the changes in bonsai.

I extended nsIPrincipal, so if you have callers of the old version's methods
prior to my change, then all that's needed is either (a) for the new
implementation to satisfy QIs to the old IID; or (b) for your code to try both
old and new IIDs in order to QI to the old interface.  I vote for (b) ;-).

/be
The MRJ Plugin JEP (like the old MRJ Plugin) calls GetOrigin() on a
pointer to an nsIPrincipal interface.  But it doesn't QI the pointer
before making the call, so the changes you've made don't require me to
make any changes (since neither GetOrigin() nor its location in the
vtable have changed).  (I've tested this with copies of Camino and
Firefox that I built today from CVS.)

Yes, I know I shouldn't do this, that it violates the basic principles
of COM ... and so forth and so forth.  But if (as the comment on the
new subsumes() method implies in nsIPrincipal.idl) the nsIPrincipal
interface will never be frozen, and might change at any time, I'd
argue that this is actually the best solution.

The nsIPrincipal vtable hasn't changed at or before the GetOrigin()
method for many years (since well before Mozilla 1.5).  You've very
nicely made your change at the end of the vtable.  With luck, future
changes will also be made there.  If and when a change is needed to
"my" part of the vtable, then I'll start doing QI checks on the
nsIPrincipal pointer (the minimum that I can get away with).

(It's a different situation for the other CAPs interface used by the
MRJ Plugin, nsIScriptSecurityManager -- I need to know its IID to get
an nsIScriptSecurityManager from nsIServiceManager::GetService().)

From the latest comment at bug 240661
(https://bugzilla.mozilla.org/show_bug.cgi?id=240661#c37), it looks
like its changes (which involve a change to the
nsIScriptSecurityManager IID) are pretty close to getting into the
trunk, and that I should change the MRJ Plugin JEP to be able to deal
with the new IID.

Am I right?

I'm probably about a week away from releasing a new version of the
JEP.  It's not a big deal if the bug 240661 changes take a while (even
a very long while) to get onto the trunk -- I'd just be adding an IID
that doesn't yet exist to my list of ones to check for.  But if anyone
has the inside dope ... :-)

I wish I could say that those changes are close to landing.  The truth is, I
have no idea when, or whether, I'll get review on that change.  :(  If I do,
then that's the IID I'll check it in with.
Thanks for letting me know ... and for promising to keep using the
same (new) IID for nsIScriptSecurityManager.

You also make changes to nsIPrincipal.idl, but it looks like you don't
change the position of GetOrigin() in the vtable.  Would you say
that's right?

If so, all I need to do is add the new IID to my list of known IIDs
for nsIScriptSecurityManager.

Yeah, I don't think my changes should affect GetOrigin.
(In reply to comment #14)
> The nsIPrincipal vtable hasn't changed at or before the GetOrigin()
> method for many years (since well before Mozilla 1.5).  You've very
> nicely made your change at the end of the vtable.  With luck, future
> changes will also be made there.

More than luck at work here: the (unwritten?  Darin or bz may know of a doc)
rule is: Always add at the end.  Whether the interface is frozen or not!

(Ok, so if I had a "totally private" interface, maybe I could have my way with
it.  But that would suggest I was abusing XPCOM, paying QI and virtual method
costs where they weren't needed.  It's exactly at the connection points between
modules (DLLs, DSOs) that XPCOM can pay off, and there it is hard to be sure
that an interface is "totally private".)

/be
Steven, bug 327242 is changing the nsIPrincipal and nsIScriptSecurityManager IIDs.  The vtable is not changing; we're just changing the scriptability of some methods, but the iid is changing because it changes what JS sees the interface to be.  :(
Depends on: 327242
Thanks for letting me know.

I assume this change is going to be trunk-only for at least a while.

Or is it?
Yeah.  The name of the game on the branches is "no interface changes".  So this change is definitely trunk-only, targeting Gecko 1.9.

There are probably going to be more interface changes in this stuff on trunk too (at least bug 327244....).  I'm still hoping that for 1.9 we can get to a point where we can freeze this stuff.  Not sure we will, though.
Depends on: 327244
I've just released a new version (0.9.5+d) of the Java Embedding Plugin that
works around the changes described in comment #20.

http://javaplugin.sourceforge.net/

People who want to do JavaScript-to-Java LiveConnect in recent Mozilla.org
nightlies for Mac OS X should:

1) Install JEP 0.9.5+d in /Library/Internet Plug-Ins/ (following the
   instructions in the JEP Readme).
2) Remove the older JEP version (JavaEmbeddingPlugin.bundle and
   MRJPlugin.plugin) from your browser's Contents/MacOS/plugins/ directory.

Depends on: 348559
Depends on: 327243
Depends on: 269270
Depends on: 354693
Depends on: 120373
Depends on: 383783
Depends on: 410851
Depends on: 418996
Alias: JEP/caps
Depends on: 413161
Depends on: 425201
Boris (or anyone else), do you know of any changes to nsIPrincipal.idl in the pipeline that haven't been landed yet?

I don't know of any myself, and am planning to release a new JEP to catch up with changes that have already been made, which I'd like to be the version included in the Firefox 3 release.
I've been adding bugs to the dependency list when I know about them.
Depends on: 396851
QA Contact: caps
Depends on: CVE-2010-0179
Can this be closed now?
Yes.  WORKSFORME isn't exactly right, but I can't think of a better way.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.