Bug 75947 introduced a new 3rd security library, named pipboot. It contains a buffering entropy collector and some code needed for the page info functionality. This functionality is required immediately after startup, but should only be activated if the security components have been compiled in. Suresh suggested, in order to avoid the overhead of yet another shared library, to find a place somewhere else in the Mozilla repository and get rid of the newly introduced module pipboot. Before we can start work, we need commitment from a different module owner, that our code is welcome. The code in question currently lives in mozilla/security/manager/boot.
Sure. Can you give a little more info on - who depends on this code - how they depend on this code (compile and run time) - who this code depends on (compile and run time) As I see it: nsEntropyCollector: depends on nothing. It is a storage point. Embedded builds will need it too. This can go into xpcom for all I care. nsSecureBrowserUIImpl: is this required for embedding too ? if not this can go into one of the appshell components or xpfe... Should this become two pieces or one piece is the big question. (Ccing Jud so he is aware of where this piece lands). (Ccing dbaron to pick his brain).
Status: NEW → ASSIGNED
Priority: -- → P3
cc'ing alec so he can provide dependency input. cc'ing chak so he can speak to the securebrowserUI
cc javi, ddrinan.
I'm leaning towards the appshell dll, or even xpcom... I guess there's a slight conflict which we need to decide on: 1) we don't want this component started unless psm is compiled in 2) this component will live in a browser or core dll, not psm This is a bit of a paradox... and it makes it difficult to implement without introducing bad dependencies... because if it lives in a non-psm dll, it somehow needs to detect if PSM is installed. In order to get that knowledge, we effectively are introducing a dependency on PSM. frankly, I'm wondering if the entropy component might be useful elsewhere, for generating random numbers and whatnot, and if we should just always start it, independent of PSM. Is it a large component, or does it slow down the running process? if not, I say lets just start it all the time and roll it into the main product. Then its just a matter of xpcom vs. appshell. I should add that my eventual plan is to split appshell into embedding and non-embedding components. If we're providing PSM support in embedding, this would be considered an embedding component.
could we stick this stuff into network?
is this as important now that PSM is lazily initialized?
that's what this is all about - PSM is lazily created, but it still needs entropy-collection to begin as soon as possible.. right now there is a stub psm library which does entropy-collection, but that means a whole seperate dll just for that. It would be nice if we could roll it into one of our dlls. as for the network suggestion, I don't like the idea just because if this truly is just entropy collection, theres nothing network-related. its more of an application service
yeah... i agree. it doesn't make sense to dump this into necko. ... how about xpcom!! ;-)
I just discovered that there is an option, at least on Linux, to compile Mozilla as a static build. (configure --enable-static --disable-shared). I think there are similar modes on Windows and Mac, too. Currently, this produces a semi static build. On Linux, instead of > 100 shared libraries, there are only 6 shared libraries in that build. (some core libs: xpcom, nspr, etc). On Unix, libstdc++ is still linked dynamically, so our LGPL license problems do not apply. I wonder: Does it make sense to work on making that build mode our default mode for distributions? If it were the default, the number of shared libraries we use for components is irrelevant for startup performance, as in distributions everything were linked statically. I still say, it is a good idea to improve startup performance - because even in a (semi-)static build, the initialization routines for components are still not executed until needed. That means, for example, even if we link statically, the enhancement from bug 75947 is still in place, because NSS init is still delayed. As tests with the statical build has shown additional performance improvements, I think this would be the preferred way to go. If you agreed that the above makes sense, this bug would become obsolete. Additional note: For development enviroments, i.e. debug mode builds, we should still compile in the shared library mode, as this enables quicker development cycles. The link stage for a static build takes quite some time, but doesn't matter when building a distribution.
CC'ing seawood regarding my previous comment. (discussed on IRC)
The static build seems completely orthogonal to this discussion as the non-static build is not going away. Not every distributor is going to want to make the static build tradeoff and we are not completely dropping our non-static release builds. (*closes eyes and concentrates really hard* please, please, please don't put the entropy collector into xpcom. Stop using xpcom as a dumping ground for utiltity classes and other non-COM related stuff )
Ok, if we are required to support both modes, this bug is still valid.
I realize nsSecureBrowserUIImpl will need additional work if we want to move it into a an "always loaded" module. As it is implemented currently, this code must not be become active, unless the other security components are available. For example, it implements a warning ConfirmPostToInsecure, which tries to show up a dialog to ask for permission. For security reasons, this class disallows posting the information by default. If we moved that unchanged into a fixed component, submitting forms would become impossible in distributions without crypto libraries :( We would be required to change that default to "allow", if security libraries are not available, or instantiation is not possible for whatever reason.
1) nsSecureBrowserUIImpl This class is accessed from both Mozilla and embedding code. It depends on several other modules to compile. It is glue code between netwerk, DOM and the security library. It hooks itself into network activity. While surfing the web, it gives information to the user about security states, and triggers several interface methods which warn the user and ask for permission in critical situations. I think XPFE looks like the best fit. 2) nsEntropyCollector This is a very primitive class which does not depend on anything else but XPCom and NSPR. The DOM module is currently the only one who is feeding entropy. It also contains the idl file already. Although jst didn't like to host all the code from module pipboot, I'd suggest to ask him whether he could host this class.
(seawood: perhaps i should have added another ;-) ...pipboot definitely has no business being part of xpcom IMO)
Ok, I'm making an executive decision: let's put pipboot appshell... however, can we make it totally generic, and call it nsEntropyCollector or something equally independent of security?
Ok Alec has made the call. Kai would that work with you ?
Assignee: dp → kaie
Status: ASSIGNED → NEW
If we put it into appshell, does this mean, the code has to duplicated for every embedding app? I think the code is generic and should be included by default by every application that uses crypto.
nooo.. we'll share it with all embedding apps, don't worry. right now appshell is required by embedding. When I rearrange the components (bug 114658) I'll make sure it gets into the right library.
Sounds good. That means, I only have one problem left. I need to detect from the code (that is not in pipboot), whether the other security libraries are available or not - but without loading the libraries to try to find out. I'm not sure how that could be accomplished. Maybe we could use write some information into the registry. Anyway, before we can move the code over, we need to write some additional code first. (see comment #13).
kai: sounds like you might want nsIServiceManager::IsServiceInstantiated
If the overhead isn't that high on the entropy collector, I think we should just start the entropy collector anyway...
Hi Kai : While you're at it can you please take a loot at http://bugzilla.mozilla.org/show_bug.cgi?id=94974 and make sure that fixing this bug(#113467) will be able to address #94974 down the road without any issues. [Summary : A while ago, to fix #94974 I added some PSM code to MfcEmbed to obtain cert info etc. and checked it. After my check in Windows Tinderboxen went red since the fix introduced a PSM dependency and i had to back out my changes]
Should the milestone on this be bumped to 1.8 something?
It seems, nowadays the pipnss gets initialized on start of Firefox anyway, so I'm marking this WONTFIX.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.