Entering all security bugs and tasks for SeaMonkey into Buzilla for schedule tracking.

The following message details the existing interface for security control of XPConnect. We need to add an implementation of nsIXPCSecurityManager that looks at the stack to see if the caller is sufficiently privileged to access XPCOM components. Subject: nsIXPCSecurityManager Date: Fri, 04 Jun 1999 12:09:47 -0700 From: jband@netscape.com (John Bandhauer) Organization: N E T S C A P E To: Norris Boyd <norris@netscape.com> CC: Mike McCabe <mccabe@netscape.com> , Mike Ang <mang@subcarrier.org> , Clayton Lewis <clayton@netscape.com> I finally got around to implementing the xpconnect security hook scheme I spoke of before. See the interface at: http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/idl/nsIXPCSecurityManager .idl Its installation at: http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/public/nsIXPConnect.h#181 And its test at: http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/tests/TestXPC.cpp#490 http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/tests/TestXPC.cpp#951 John.

Not enough time to implement for M9.

Code is in, but the body of nsScriptSecurityManager::CheckXPCPermissions is ifdef'd out. When it was enabled, it caused orange trees on the Linux tinderbox (builds passed, but tests failed). I don't know what sort of failures it caused or how to run those tests.

Any chance that nsScriptSecurityManager::CheckXPCPermissions has been re-enabled, and no longer causes orange trees? I will check on 7261 dependencies. If dependencies are satisfied, I'll set this verified. (dependency 7268 will require a simple set of DOM security tests that should pass to satisfy "initial implementation".) (dependency 11145 verified)

Yes, the preference is no longer disabled but doesn't cause any known regressions.

Bulk moving all Browser Security bugs to new Security: General component. The previous Security component for Browser will be deleted.

Verified based upon dependencies being verified.