129042 - Make S/Mime more modular

Status: RESOLVED WONTFIX

(MailNews Core :: Security: S/MIME, enhancement, P4)

Description

[Henrik Gemal]

if PSM is not installed I'm getting this when starting mail&news:

Warning: reference to undefined property Components.interfaces.nsIPKIParamBlock
Source File: chrome://messenger-smime/content/msgReadSMIMEOverlay.js
Line: 43

20020304

Comment 1

[Stephane Saux]

kai

Comment 2

[Stephane Saux]

actually this is invalid. There's no way we're going to ahve s/mime without PSM.
msgReadSMIMEOverlay can be compiled out and should certainly not be present if
PSM is not present.

Comment 3

[Henrik Gemal]

the bug report is perfectly legal. You should *never* get strict warnings. I
dont care if PSM is installed or not.
You just have to strengthen the check.

something like:
if "nsIPKIParamBlock" in Components.interfaces
bla bla bla

Comment 4

[Kai Engert (:KaiE:)]

Well, at installation time, you can choose which packages you want.

S/Mime is a package, that depends on both mail/news and psm. Currently, it is
installed together with mail/news.

Instead, it should only get installed, if both mail/news and psm get installed.
I talked to dveditz, and he thinks we are currently unable to create installer
rules with multiple parents dependencies.

However, even if we installled the smime library only if both mail/news and psm
get installed, this doesn't solve the problem, because we still have the UI
overlays.

Therefore, I'm changing this bug into an enhancement request, to make S/Mime
completely modular.

In order to fix it, we would have to create a new separate XPI file, and make
sure everything related to S/Mime is moved there.

Comment 5

[Kai Engert (:KaiE:)]

*** Bug 124912 has been marked as a duplicate of this bug. ***

Comment 6

[Stephane Saux]

Henrik is right. I'm a strong supporter of no strict warning period.

Comment 7

[timeless]

i'm a strong supporter of non fatal asserts for non important missing 
dependencies...

Comment 8

[Kai Engert (:KaiE:)]

*** Bug 143027 has been marked as a duplicate of this bug. ***

Comment 9

[Charles Rosendahl]

The question is:  If you make the packages completely modular, how will the non
s/mime, non PSM mail client react when opening signed and/or encrypted messages?

Hopefully not like Bug 143027.

Comment 10

[Kai Engert (:KaiE:)]

In order to fix any errors produced by overlays, that get activated because the
S/Mime extension is loaded, while PSM is not, see comment 4.

In order to fix the reported crash, it should be determined at runtime, whether
S/Mime is available or not. Currently that is done at compile time.

At compile time, the mime parser decides that it should handle the S/Mime mime
types. But it should not do that unless both the S/Mime extension and PSM are
installed.

Comment 11

[Kai Engert (:KaiE:)]

*** Bug 120305 has been marked as a duplicate of this bug. ***

Comment 12

[Kai Engert (:KaiE:)]

*** Bug 130293 has been marked as a duplicate of this bug. ***

Comment 13

[Kai Engert (:KaiE:)]

*** Bug 130294 has been marked as a duplicate of this bug. ***

Comment 14

[Kai Engert (:KaiE:)]

Things have changed during the previous 8 years.
PSM and crypto is now an integral part of the core platform, it's no longer optional.

-> wontfix