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

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.

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

nsIPrincipal's iid just changed again -- bug 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. :(

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.

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.

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.

Can this be closed now?

Yes. WORKSFORME isn't exactly right, but I can't think of a better way.