Closed Bug 113467 Opened 23 years ago Closed 18 years ago

Find a new home for some PSM code

Categories

(Core Graveyard :: Security: UI, defect, P3)

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
psm2.2

People

(Reporter: KaiE, Assigned: KaiE)

References

Details

(Whiteboard: [kerh-cuz]) 

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.
Blocks: 7251
Target Milestone: --- → 2.2
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... 
nsbeta1
Keywords: nsbeta1
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]
Keywords: nsbeta1 → nsbeta1-
Blocks: entropy
Keywords: nsbeta1
Keywords: nsbeta1-
Should the milestone on this be bumped to 1.8 something?
Product: PSM → Core
Whiteboard: [kerh-cuz]
It seems, nowadays the pipnss gets initialized on start of Firefox anyway, so I'm marking this WONTFIX.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
Version: psm2.1 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.