Benjamin Smedberg wrote: > I have no particular opinion about whether this is a good idea for > NSS. I do think that we should not do this for NSPR unless we > decide to remove support for binary XPCOM components in Firefox > (per the ongoing discussion in dev.planning). Many of our XPCOM > code patterns assume/require use of NSPR, and I don't think it's > the right time to try changing that.
NSPR is not nearly as big as NSS and we use a large percentage of NSPR functionality. So, this kind of "dead code" elimination for NSPR would not necessarily be a justifiable win considering potential compatibility pain, like it would be for NSS. And also, I don't know (yet) of any startup time, correctness, or security wins from doing this for NSPR, like I do know for NSS. Even if we link NSS and/or NSPR into libxul, we can easily create forwarder DLLs with the old DLL names that forward calls to the retained functions in libxul, so that any binary components that link to NSS/NSPR and only use the NSS/NSPR functions we retain will work correctly. > > 3. Help out with the DOMCrypt effort that ddahl is leading, which > > will create a W3C-standardized Javascript API for cryptography for > > *web* applications. I suspect it would be non-trivial, but > > possible, to expose the DOMCrypt API to extensions. I suspect that > > this would replace APIs from #1 and #2 above. > I tend to think that extensions would get this basically "for free" > because they have access to the DOM. It is likely that DOMCrypt will base part of its key management system on a same-origin policy, and that origin-based key management policy is likely to be inappropriate for a bunch of applications. Also, I do not know how JetPack (Addon SDK) deals with any "origin", and I bet there will need to be some new/different glue to get DOMCrypt to fit into the JetPack model. - Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
