Re: Remote Controlling A C++ XPCOM Component In A Signed JavaScript Page In a HttpS WebSite
Jean-Marc Desperrier
> I have written a XPCOM C++ Components.
> [...] It work in signed JAR and
> requested privilege("UniversalXPConnect") is accepted from remote host
> because it is signed.
>
> But the problem is, I want to use this component into a HTTPS page.
> And when I run this page, i got in Javascript console:
>
> Error: uncaught exception: [Exception... "Component returned failure code:
> 0x80570018
> [...]
> Did someone have any idear of what happen?
This code extremly little used. You probably have found a bug in which
the permissions are not correctly transmitted for htpps pages.
> Why it work in http?
> Why my https Site work too?
> And Why "Remote Controlling A C++ XPCOM Component In A Signed JavaScript
> Page In a HttpS WebSite don't work"?
What do you mean by the https site works too ? Do you mean the fact it
works as long as you don't try to run signed javascript from it ?
There's an old bug that looks very similar, but the reporter never gave
enough information for reproduction, so it was closed :
https://bugzilla.mozilla.org/show_bug.cgi?id=90310
Can you test what happens with a simpler script that uses
UniversalXPConnect, but not your XPCOM component, like the one in this
message :
http://groups.google.fr/groups?selm=96f084a3.0308190144.5e6d2c19%40posting.google.com
If it fails, then it would be good to attache it to 90310, and reopen
the bug.
I'm redirecting the discussion to netscape.public.mozilla.crypto
Jean-Marc Desperrier
> What do you mean by the https site works too ? Do you mean the fact it
> works as long as you don't try to run signed javascript from it ?
>
> There's an old bug that looks very similar, but the reporter never gave
> enough information for reproduction, so it was closed :
> https://bugzilla.mozilla.org/show_bug.cgi?id=90310
I think this patch too is a little suspicious :
https://bugzilla.mozilla.org/show_bug.cgi?id=240496
Nelson B
> Vincent THOREL wrote:
>> Error: uncaught exception: [Exception... "Component returned failure
>> code: 0x80570018
Jean-Marc, Do you know what that error code means, and/or what produced it?
It is not an NSS or NSPR error code. It looks like a Microsoft style error
code, e.g. 0x80nn0xxx but I cannot find it in my MS header files, nor on
the msdn web site. I also searched lxr.mozilla.org for that string and
various substrings without results.
If you know where it is defined, please post a reference. Thanks.
--
Nelson B
Jean-Marc Desperrier
> Jean-Marc Desperrier wrote:
>>> Error: uncaught exception: [Exception... "Component returned failure
>>> code: 0x80570018
>
> Jean-Marc, Do you know what that error code means, and/or what produced
> it?
> If you know where it is defined, please post a reference. Thanks.
Nelson, maybe I was wrong to transfer to crypto, because I don't believe
it has to see with NSS. Maybe I it would better have left it in security
or transferred to XPCOM. Just saw signature + ssl, but if the actual
cryptography layer is OK, it's still component security.
I made things harder by cutting too much from the original message,
where it was easy to spot the NS_ERROR_XPC_BAD_IID identifier, but you
probably saw it on the security group ?
http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/idl/nsIXPConnect.idl#98
#define NS_ERROR_XPC_BAD_IID GENERATE_XPC_FAILURE(24)
#define GENERATE_XPC_FAILURE(x) \
(NS_ERROR_GENERATE_FAILURE(NS_ERROR_MODULE_XPCONNECT,x))
#define NS_ERROR_MODULE_XPCONNECT 18
#define NS_ERROR_GENERATE_FAILURE(module,code) \
((nsresult) (((PRUint32)(NS_ERROR_SEVERITY_ERROR)<<31) |
((PRUint32)(module+NS_ERROR_MODULE_BASE_OFFSET)<<16) |
((PRUint32)(code))) )
#define NS_ERROR_MODULE_BASE_OFFSET 0x45
0x45 + 18 = 0x57, and 24 => 0x18
The thing is that this error is in all case returned after the security
manager has done the checking, so this is something else. It seems in
the https version the js jut can't see his XPCOM component. It sounds
possible it's just a inadvertent installation error.
If the installation of the component is really correct, I think Vincent
should run his component in a debug build, set breakpoints everywhere
this error is returned, and check what is different when he reaches this
points in the HTTP and in the HTTPS version.
The error can come from :
/js/src/xpconnect/src/xpccomponents.cpp, line 1654
/js/src/xpconnect/src/xpcjsid.cpp, line 795
/js/src/xpconnect/src/xpcjsid.cpp, line 883
Nelson B
> I made things harder by cutting too much from the original message,
> where it was easy to spot the NS_ERROR_XPC_BAD_IID identifier, but you
> probably saw it on the security group ?
Thanks for the added info Jean-Marc. I didn't see this in n.p.m.security.
--
Nelson B