419030 - FF2 should pick up NSS fixes, but keep the FIPS approved softoken module

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Rob Stradling]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

The OCSP Response for the ocsptest.comodoca.com SSL Server Certificate is signed by the same Trusted Root CA Certificate that issued the SSL Server Certificate. There are no Intermediates CA Certificates involved anywhere. There is no delegation to a separate OCSP Signing Certificate. So this is really the simplest possible PKI configuration for OCSP.
This same -8048 error occurs regardless of whether:
  - the OCSP Response uses "ResponderID.byName" or "ResponderID.byKey".
  - the OCSP Response includes no certificates or includes the Trusted Root CA Certificate.

This problem occurs in Firefox 2.0.0.12 (tested on XP, Vista and Linux) and a 2.0.0.13pre nightly build from a couple of days ago (tested on XP).
This problem also occurs in Firefox 1.5.0.12 (so it must have been around for a while).
There is no problem in Firefox 3 Beta 3 (presumably because the underlying NSS OCSP support has been heavily modified to cope with EV SSL Certificates).

Has the Firefox 1/2 OCSP code ever been shown to work when the OCSP Response signer is a built-in Trusted Root Certificate?  Or does it only work properly when delegating to a separate OCSP Signing Certificate (using the ocspSigning EKU OID)?
Or can anybody see anything else problematic with the OCSP Response?

(Interestingly, when I compile the current Gentoo Linux Firefox 2.0.0.12 source package, the problem doesn't occur. My guess is that it's linking to a newer version of NSS than the official Firefox 2.0.0.12 binary builds).

Reproducible: Always

Steps to Reproduce:
1. In Firefox 2.x (or 1.5.x), enable OCSP checking for "certificates that specify an OCSP Service URL".
2. Browse to https://ocsptest.comodoca.com

Actual Results:  
A popup window displays "Error establishing an encrypted connection to ocsptest.comodoca.com. Error Code: -8048.", and the browser refuses to navigate to the webpage.

Expected Results:  
No popup window, and successful navigation to the webpage.

The following software accepts the OCSP Response without any problem:
  - IE7 (Vista).
  - Opera 9.23 (Linux).
  - OpenSSL's command line tool.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

The problem described here is bug 381317.  
That bug was fixed in NSS 3.11.7  nine months ago.
I cannot reproduce the symptoms described above using a recent NSS 3.11.x
branch build (that's the branch that is used in FF 2).
This makes me wonder if the FF 2 build that you have was built with an 
old version of NSS, older than 3.11.7.  

Can you tell me the file version of the file nss3.dll (on windows) or 
libnss3.so (on Linux), a.k.a. libnss3.dylib and libnss3.sl on other platforms?

Comment 2

[Robin Alden]

In "C:\Program Files\Mozilla Firefox\nss3.dll" is version 3.11.5.0

From my install log:-
Mozilla Firefox Installation Started: 2008-02-18 15:49:06
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
Installation Details
-------------------------------------------------------------------------------
  Install Dir: C:\Program Files\Mozilla Firefox
  Locale     : en-GB
  App Version: 2.0.0.12
  GRE Version: 1.8.1.12

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

well, that explains that.  This is not an NSS bug (any more).
This is a Firefox build bug.

Comment 4

[Rob Stradling]

Nelson, thanks a lot for your help.  This has been confusing me all week.

The pre-built Firefox 2.0.0.12 binary on my Gentoo Linux system also seems to be using NSS 3.11.5:

# objdump -s /opt/firefox/libnss3.so | grep "NSS 3.11." -A 2
 5cee0 40282329 4e535320 332e3131 2e352042  @(#)NSS 3.11.5 B
 5cef0 61736963 20454343 20204665 62202031  asic ECC  Feb  1
 5cf00 20323030 38203231 3a33363a 33340000   2008 21:36:34..

Can this problem be fixed in time for Firefox 2.0.0.13 ?

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Here's what I know about this issue.
NSS has several separable components, each of which has its own version 
number.  Those components are (essentially, this is rather simplified):

  - The PKCS#11 module that does all the cryptography. This module is the
        part of NSS that has been FIPS 140 certified.  It includes the 
        shared libraries softoken and freebl.  
  - The PKCS#11 module that holds the trusted roots.  This is one shared 
        library, nssckbi.
  - All the rest of NSS

The NSS team does not support arbitrary combinations of those components.
We only support certain tested and "blessed" combinations.  
We try to avoid mixing old versions of one component with newer versions 
of another, but we have made, and do make, exceptions to that.  From time
to time, we have produced NSS tags that represent combinations of old 
versions of some components and new versions of others.  We have done this
for Firefox 2, at the request of Mozilla (Frank Hecker, I think).  

In order for Firefox 2 to continue to be able to claim that it uses FIPS 
certified crypto, it must continue to use the version of the PKCS#11 crypto 
module that was FIPS certified.  The version of the PKCS#11 crypto module 
that was last FIPS certified was version 3.11.5.  That version is now 
rather old.  Since then there have been many additions to nssckbi, the 
module that contains the trusted root CA certs.  Mozilla wants to incorporate
the latest root certs module, while keeping the FIPS certified crypto module.

So, the NSS team has been making CVS tags for use in FF2.x releases that 
consist of the latest version of nssckbi (the root certs module), and 
version 3.11.5 of the rest of NSS.  Examples of those tags include:
- NSS_3_11_5_WITH_CKBI_1_64_RTM
- NSS_3_11_5_WITH_CKBI_1_65_RTM

Each of those tags has new nssckbi, old softoken, and old everything else.
That has been what Mozilla has specifically requested.

IMO, what we SHOULD be making, and what Mozilla SHOULD be requesting, is a 
tag that is the latest nssckbi, the old softoken, and the latest everything
else.  The only part of NSS that needs to be kept old for FIPS purposes is
the crypto module (softoken and freebl).  Such a tag might be named (for 
example) NSS_3_11_9_WITH_SOFTOKEN_3_11_5

By staying with the old version of the rest of NSS, FF2 doesn't get any of 
the bug fixes made for NSS since 3.11.5, including bug fixes that are done
primarily for the browser (such as the fix for bug 381317).

But until Mozilla requests a tag for the combination that I recommend, such
a tag will not be produced.  

Comment 6

[Rob Stradling]

Nelson, thanks for your insight.

> IMO, what we SHOULD be making, and what Mozilla SHOULD be requesting,...
> ...
> ...NSS_3_11_9_WITH_SOFTOKEN_3_11_5

Makes sense to me.

> But until Mozilla requests a tag for the combination that I recommend...

We at Comodo would very much like to see this happen.
Should we submit a new enhancement request? Or will this bug suffice?

Comment 7

[Samuel Sidler (old account; do not CC)]

(In reply to comment #5)
> From time to time, we have produced NSS tags that represent combinations of
> old versions of some components and new versions of others.  We have done 
> this for Firefox 2, at the request of Mozilla (Frank Hecker, I think).  
> 
> IMO, what we SHOULD be making, and what Mozilla SHOULD be requesting, is a 
> tag that is the latest nssckbi, the old softoken, and the latest everything
> else.  The only part of NSS that needs to be kept old for FIPS purposes is
> the crypto module (softoken and freebl).  Such a tag might be named (for 
> example) NSS_3_11_9_WITH_SOFTOKEN_3_11_5
> 
> But until Mozilla requests a tag for the combination that I recommend, such
> a tag will not be produced.

Frank, what do you want to do here? 

(For the record and for easier triaging later, we just upgraded NSS on the branch to NSS_3_11_5_WITH_CKBI_1_65_RTM in bug 416202.)

Comment 8

[Wan-Teh Chang]

Another option is for Mozilla to say "use Firefox 2.0.0.1 - 2.0.0.12 if you
must use a FIPS validated version".  Then Mozilla is free to upgrade
to the latest NSS 3.11.x release in Firefox 2.0.0.13.

Comment 9

[Samuel Sidler (old account; do not CC)]

I'm not sure I consider that an option, given that those users would be vulnerable to any security fixes we make in 2.0.0.13 or later.

If this is really that important, we should get another version of the PKCS#11 crypto module certified. I'm not sure what that process looks like, however.

Comment 10

[Robert Relyea]

So currently the issue is there is a limited number of fixes that mozilla accepts in security releases, and a limited number of versions that the NSS team supports.

To date, FF 2.0 has only picked up built in changes. The viability of an NSS 3.11.x (x > 5) with an NSS 3.11.5 softoken (actually NSS  3.11.4, there were no changes to softoken between 3.11.5 and 3.11.4) has been proven by redhat releases of NSS which do this mixing.

Because of the weight of a FIPS validation, currently the next targeted version for FIPS is a 3.12 softoken.

Comment 11

[Kai Engert (:KaiE:)]

So, I'd like to give some additional details over the proposal that Nelson made, and which Bob cited we're doing at Red Hat.

My understanding is:

If you want to build FIPS approved binaries of softoken and freebl, you must use the full set of approved sources that are linked in statically with that module.

Compiling+Linking the freebl/softoken libraries requires that you include portions of NSS described as the "NSS base" and "NSS util" libraries.

So, when compiling freelbl+softoken of FIPS approved version 3.11.5, you must compile using base and util code of the same version, 3.11.5

However, the rest of NSS 3.11.9 will not build with base+util version 3.11.5 !!!

Because of that problem, we're doing extra work for building the packages for out Linux distribution.

We build freebl+softoken using base+util all from version 3.11.5

We build the rest of NSS using base+util from the more recent version.

In other words, for a single NSS build, we use two different copies of base+util.

This means it is impossible to follow the current style of a single NSS tag. It requires mixing at least two different tags.

This also means the build process would have to get adjusted and becomes more complicated.

Yes, we could produce that NSS_3_11_9_WITH_SOFTOKEN_3_11_5 source code tag, but IINM building NSS from this tag would NOT give you a FIPS approved binary.

Comment 12

[Wan-Teh Chang]

Kai, your understanding is mostly correct, except that freebl and softoken depend only on util.  They don't depend on base.  (On the other hand, nssckbi depends on base, but not util.)

No application vendor has the money or time to FIPS-validate every version of their
application.  We do our best to stay FIPS-validated, but eventually we will need to fix
a bug in the validated code.  The customers who must use FIPS-validated apps
decide whether strict FIPS compliance or critical bug fixes are more important.  Our
job is to make sure the bug fixes that force us to diverge from the validated code are
really critical bug fixes.

Comment 13

[Daniel Veditz [:dveditz]]

Not "blocking" 2.0.0.13, but we'd like to get this worked out.

(In reply to comment #5)
> The only part of NSS that needs to be kept old for FIPS purposes is
> the crypto module (softoken and freebl).  Such a tag might be named (for 
> example) NSS_3_11_9_WITH_SOFTOKEN_3_11_5

I don't think anyone ever bothered to explain that.

In addition to wanting to stick with the FIPS certified code, we have a general reluctance to upgrade libraries in security releases just for the sake of using the latest. If there are significant bugs fixed in those versions then given enough of those (which might be only one if it's a security problem) we would of course prefer to upgrade to a QA'd supported tag than to take individual fixes.

Rather than simply say "FF2 should use a new library" a better approach would be to point to the specific bugs and say they ought to be fixed, and the fix is a new library. Otherwise when presented with a "switch library" request we see only the risk and none of the gain, and Firefox QA isn't going to sign up for that.

Code freeze for FF2.0.0.13 is scheduled for March 7, a change this large is better scheduled for the beginning of a release cycle, not the end.

Comment 14

[Rob Stradling]

(in reply to comment #13)
> Code freeze for FF2.0.0.13 is scheduled for March 7, a change this large is
> better scheduled for the beginning of a release cycle, not the end.

Please reconsider the urgency of this bug.

When Firefox 3.0.0.0 is launched, it will absolutely require CAs to include OCSP URLs in their EV SSL Certificates in order to cause the new EV UI to be displayed.
So...
  - CAs *must* deploy OCSP for Firefox 3.0.0.0
  - Some CAs *cannot* deploy OCSP without triggering this -8048 error in Firefox 2.x

Please see Bug #413997 Comment #10 for some further thoughts from me on this issue.

OCSP in FF2 is disabled by default.  I have no idea what % of FF2 users have chosen to enable it.  So...
Best case scenario: the number of FF2 users seeing the -8048 error might not increase too much once FF3 is launched and more (EV) CAs have rolled out OCSP.
Worst case scenario: the number of FF2 users seeing the -8048 error might increase dramatically, causing an increase in: support requests to CAs, duplicate bugs in Bugzilla, unhappy end-users and unhappy HTTPS website operators.

If it's at all possible, I would really like to see this FF2 OCSP bug resolved in a Firefox 2.0.0.x release that occurs no later than the launch of Firefox 3.0.0.0.

Comment 15

[Rob Stradling]

(in reply to comment #13)
> Code freeze for FF2.0.0.13 is scheduled for March 7, a change this large is
> better scheduled for the beginning of a release cycle, not the end.

Firefox 2.0.0.13 has been released.  Will you now schedule this change?

Comment 16

[Rob Stradling]

Firefox 2.0.0.14 has been released.  Will you now schedule this change?

Comment 17

[:Gavin Sharp [email: [e-mail]]]

Firefox 2.0.0.14 was a firedrill to address a topcrash introduced in Firefox 2.0.0.13. It's scope was limited to get it out fast. This bug is being tracked for Firefox 2.0.0.15 which should be released in a regularly scheduled security update milestone (barring any potential need for another firedrill).

Comment 18

[Daniel Veditz [:dveditz]]

(In reply to comment #5)
> But until Mozilla requests a tag for the combination that I recommend, such
> a tag will not be produced.  

Please produce a supported NSS tag for Firefox 2 to use.

Comment 19

[Daniel Veditz [:dveditz]]

assigning to Nelson to tell us what we need to do. Please reassign to someone else who can produce the tag if you're not able to do it.

Comment 20

[Nelson Bolyard (seldom reads bugmail)]

I'm giving this bug back to Firefox. 
I will create a separate NSS bug and mark it as blocking this bug.

Comment 21

[Kai Engert (:KaiE:)]

Attachment: Patch v1

Here is a patch that appears to work, at least on Linux.
Other platforms not yet tested.
We must test this on other platforms before landing.

It does not require a new tag, but pulls two different tags, and does selective building / cleaning / building.

Thanks a lot to Bob Relyea, I wouldn't have been able to get this done without your help.

(Although the patch looks simple, it feels like I grew my first grey hairs ;-) )

Comment 22

[Robert Relyea]

Comment on attachment 319099 [details] [diff] [review]
Patch v1

r- 

1) cd .. should be cd ../..
2) Create the config with the checkout so it's part of the regular source for mozilla (and we don't have a write to the build tree during build time).

bob

Comment 23

[Kai Engert (:KaiE:)]

Attachment: Patch v2

Comment 24

[Robert Relyea]

Comment on attachment 319101 [details] [diff] [review]
Patch v2

r+ rrelyea

Comment 25

[Wan-Teh Chang]

Comment on attachment 319101 [details] [diff] [review]
Patch v2

I suggest that you use "nss-fips" or "nss-3.11.4" instead of "nss3114".

I suggest you change NSS_CRYPTO_XXX to NSS_FIPS_XXX.

Congratulations!

Comment 26

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 319101 [details] [diff] [review]
Patch v2

Doesn't this patch have the effect that the NSS 3.11.latest part 
(outside of freebl+softoken) is built using header files from 
NSS 3.11.4 for softoken and freebl?

Doesn't this cause the "gmake export" that occurs after building 
NSS 3.11.4 to have no effect, not changing any header files used in 
the rest of the build?

Comment 27

[Kai Engert (:KaiE:)]

(In reply to comment #26)
> Doesn't this patch have the effect that the NSS 3.11.latest part 
> (outside of freebl+softoken) is built using header files from 
> NSS 3.11.4 for softoken and freebl?

I think that's exactly what we want?


> Doesn't this cause the "gmake export" that occurs after building 
> NSS 3.11.4 to have no effect, not changing any header files used in 
> the rest of the build?

I see only a single call to an "export" make target in my patch, which is for CMD/lib.

I promise you that it has an effect, because without that export the build of libssl fails, because it requires secutil.h

Comment 28

[Kai Engert (:KaiE:)]

Attachment: Patch v2 + renames

(In reply to comment #25)
> I suggest that you use "nss-fips" or "nss-3.11.4" instead of "nss3114".
> I suggest you change NSS_CRYPTO_XXX to NSS_FIPS_XXX.

I like these proposals.
I used search/replace in the patch.

Comment 29

[Wan-Teh Chang]

Comment on attachment 319101 [details] [diff] [review]
Patch v2

>+	cd mozilla/security; \
>+	cvs_co $(CVSCO_CRYPTO_NSS); \
>+	echo "DIRS=\"util freebl softoken\"" > $(NSS_CRYPTO_CO_DIR)/lib/config.mk ;\
>+	echo "DIRS=\"util base dev pki pki1 certdb certhigh pk11wrap cryptohi nss ssl pkcs12 pkcs7 smime crmf jar ckfw\"" > nss/lib/config.mk ;\
>+	cd ../..; \

You create these two config.mk files, but they are not being
used.

I think Bob also patched nss/lib/Makefile to include (the local)
config.mk.

>+	$(MAKE) -C $(topsrcdir)/security/nss3114/lib/util $(DEFAULT_GMAKE_FLAGS) clean
>+	$(MAKE) -C $(topsrcdir)/security/nss3114/lib $(DEFAULT_GMAKE_FLAGS)
>+	$(MAKE) -C $(topsrcdir)/security/nss3114/lib/util $(DEFAULT_GMAKE_FLAGS) clean
>+ifndef SKIP_CHK
>+	$(MAKE) -C $(topsrcdir)/security/nss/cmd/lib $(DEFAULT_GMAKE_FLAGS) export
>+endif
> 	$(MAKE) -C $(topsrcdir)/security/nss/lib $(DEFAULT_GMAKE_FLAGS)
> ifndef SKIP_CHK
> 	$(MAKE) -C $(topsrcdir)/security/nss/cmd/lib $(DEFAULT_GMAKE_FLAGS)
> 	$(MAKE) -C $(topsrcdir)/security/nss/cmd/shlibsign $(DEFAULT_GMAKE_FLAGS)
> endif

This is wrong.  Did you run ident on libsoftokn3.so and
libfreebl3.so?  Are they version 3.11.4?

Comment 30

[Kai Engert (:KaiE:)]

(In reply to comment #29)
> 
> You create these two config.mk files, but they are not being
> used.

Sigh. You are right. Bob had proposed it, and I simply assumed they would always be used when present, without doublechecking.

I was searching for an alternative to specifying DIRS= on the command line, because that has the effect that the DIRS= variable is being unnecessarily used at additional directory levels.


> This is wrong.  Did you run ident on libsoftokn3.so and
> libfreebl3.so?  Are they version 3.11.4?

Sigh. Yes.

Comment 31

[Kai Engert (:KaiE:)]

Attachment: Patch v3

As I said a couple of days ago, we can easily solve it by duplicating the files manifest.mn and Makefile contained in security/nss/lib,

where the new duplicated files have freebl/softoken removed from their DIRS variable.

I have tried to simulate that by specifying DIRS="....." variables in the environment, or as a parameter, to make, but that fails to build.

I have tried to build in the subdirectories only, but that fails to build, too. Apparently some required magic happens when building in the security/nss/lib level.

This patch works for me.
It requires the duplicated makefile/manifest.
I used "ident" to confirm that freebl/softoken are 3.11.4 and the other .so files are 3.11.9

I think you have rejected the makefile duplication proposal, because you think it't not elegant. It would be really great if you could help out and implement the more elegant solution you have in mind.

Comment 32

[Kai Engert (:KaiE:)]

Attachment: Patch v4

One more attempt to get it working without Makefile duplication.

Why does this work now?
Why am I no longer getting the build failures I previously saw when using the DIRS="..." approach?

I used "ident" and everything looks fine (freelb/softoken 3.11.4, all other .so are 3.11.)

I had used less export/install commands in my previous attempts, looks like all these steps are required.

You should be able to diff patch v3 against v4.

Comment 33

[Kai Engert (:KaiE:)]

FYI, with patch v4 I see the following message 1764 times:
  "Skipping non-directory <some entry from the DIRS variable>..."

Comment 34

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 319116 [details] [diff] [review]
Patch v4

Here are a number of comments about this patch.  
There are suggestions here that IMO would improve it.
This is not a review; that is, there is no r+ or r- associated
with these comments.

1) The change to use cvs co -d to checkout of existing RCS/CVS 
files, rather than creating new RCS files in security/nss-fips,
is a HUGE improvement to this plan, and I thank whoever came up 
with that improvement.

2) Instead of the new sequence 

>+	cd mozilla/security; \
>+	cvs_co $(CVSCO_FIPS_NSS); \
>+	cd ../..; \

You might use 
       (cd mozilla/security; cvs_co $(CVSCO_FIPS_NSS)); \

The extra parentheses around those two commands cause them to 
be done in a subshell.  The subshell does the cd command, and
when it is done, it exits.  The parent shell has not done the 
cd command, and so does not need to do a cd ../..
This can be done in two places.

3) The patch to Makefile.in embeds into PSM's makefile a lot of 
knowledge about the internal directory structure of NSS.  
Consequently, future changes to NSS's internal directory structure
will necessitate changes to PSM's makefile.in also.  I think that's
undesirable.  It would be better, IMO, if the knowledge of NSS's
directories remained entirely within NSS files.  

I might suggest adding a target to nss/Makefile (the one that gets checked out 
for the nss-fips directory) to do the following steps.  

Would a small addition to that particular Makefile invalidate the FIPS 
evaluation?  If so, then I might consider adding a new makefile to the 
nss directory, with a name like Makefile.FIPS, and tag it with the 3.11.4
RTM tag, then use that Makefile in nss-fips instead of the existing one.  

>-	$(MAKE) -C $(topsrcdir)/security/nss/lib $(DEFAULT_GMAKE_FLAGS)
>+	$(MAKE) -C $(topsrcdir)/security/nss-fips/lib/util $(DEFAULT_GMAKE_FLAGS) clean
>+	$(MAKE) -C $(topsrcdir)/security/nss-fips/lib $(DEFAULT_GMAKE_FLAGS) export
>+	$(MAKE) -C $(topsrcdir)/security/nss-fips/lib/util $(DEFAULT_GMAKE_FLAGS)
>+	$(MAKE) -C $(topsrcdir)/security/nss-fips/lib/util $(DEFAULT_GMAKE_FLAGS) install
>+	$(MAKE) -C $(topsrcdir)/security/nss-fips/lib/freebl $(DEFAULT_GMAKE_FLAGS)
>+	$(MAKE) -C $(topsrcdir)/security/nss-fips/lib/freebl $(DEFAULT_GMAKE_FLAGS) install
>+	$(MAKE) -C $(topsrcdir)/security/nss-fips/lib/softoken $(DEFAULT_GMAKE_FLAGS)
>+	$(MAKE) -C $(topsrcdir)/security/nss-fips/lib/softoken $(DEFAULT_GMAKE_FLAGS) install
>+	$(MAKE) -C $(topsrcdir)/security/nss-fips/lib/util $(DEFAULT_GMAKE_FLAGS) clean
>+ifndef SKIP_CHK
>+	$(MAKE) -C $(topsrcdir)/security/nss/cmd/lib $(DEFAULT_GMAKE_FLAGS) export
>+endif

4) The lines below invoke MAKE 3 times with the same command line arguments 
except for one trailing argument which is the target.

>+	$(MAKE) -C $(topsrcdir)/security/nss/lib $(DEFAULT_GMAKE_FLAGS) DIRS="util base dev pki pki1 certdb certhigh pk11wrap cryptohi nss ssl pkcs12 pkcs7 smime crmf jar ckfw ckfw/builtins" export
>+	$(MAKE) -C $(topsrcdir)/security/nss/lib $(DEFAULT_GMAKE_FLAGS) DIRS="util base dev pki pki1 certdb certhigh pk11wrap cryptohi nss ssl pkcs12 pkcs7 smime crmf jar ckfw ckfw/builtins" install
>+	$(MAKE) -C $(topsrcdir)/security/nss/lib $(DEFAULT_GMAKE_FLAGS) DIRS="util base dev pki pki1 certdb certhigh pk11wrap cryptohi nss ssl pkcs12 pkcs7 smime crmf jar ckfw ckfw/builtins"

The 3 targets are: export, install, and (empty, the default target).
The default target is "all", defined in coreconf/rules.mk.  That "all"
target is equivalent to two other targets, which are: export, libs

So, those 3 commands are equivalent to a single command that is:
$(MAKE) <args> export install all
which is equivalent to 
$(MAKE) <args> export install export libs

However, IIRC, install is equivalent to libs, so this is equivalent to
$(MAKE) <args> export libs export libs
or 
$(MAKE) <args> all all
So, this effectively does two full build passes over nss.
I'm not sure what the second pass accomplishes.

These lines also suffer from the fact that they embed knowledge of NSS's
directory structure into PSM.  Since these lines are building nss 3.11.latest
and not 3.11.4, there is no question that the knowledge for these steps
can be embedded into nss Makefiles in any of several ways (a separate 
target, or the value of DIRS can depend on the existence of a make/shell
variable), and PSM can invoke the NSS 3.11.latest makefiles with that
target or variable.  There is precedent for this.  See nss/lib/Makefile
for code that modifies DIRS based on a make/shell variable.

Comment 35

[Kai Engert (:KaiE:)]

Nelson,

the latest patch attached to this bug has the following advantages:

- it works already (at least it appears to me)
  and if I'm right, no further work, no further experimentation,
  no further hours of running test builds is required

- it works with the existing releases and tags,
  while your proposal requires new work, new makefiles,
  checkins to nss, more testing, maybe even a new release of nss?

Yes, the PSM makefile might duplicate some knowledge about the internal structure of NSS, but is it really that bad?
We are on stable branches, both Firefox and NSS.
Do we really expect a lot of changes on that stable branch?
And should things really change and the build fail, we'll notice.


Furthermore, based on an email exchange we had a couple of days ago, I had conclude that you have vetoed the idea to create new, separate, additional makefiles at the NSS level, so your new proposal sounds like a late change of plans.

I'd like to avoid going back, change the plan and do more work, if possible.
But of course, should we identify that the current proposal (patch) does not work for some reason, that's a different story.

Comment 36

[Kai Engert (:KaiE:)]

I think we should separate solutions based on their approach.

Approach (a):
Avoid all changes to NSS.

Approach (b):
Solve it completely at the NSS level.

Approach (c):
Do a mix of NSS and PSM/Firefox changes.


I were unable to find an agreeable and doable solution that uses approach (b).

So I had attempted to do (c).

But my ideas for the NSS portions of (c) did not find a lot of friends, so I have tried to find a solution that uses approach (a).


This is a Firefox bug.
The latest patch follows approach (a).
(It hope it really works, but we need to do testing on other platforms than Linux.)


I propose that discussions and work for solutions based on approach (b) or (c) should happen in NSS bug 431204.


If patch v4 works, and NSS developer do not reject it as "incorrect", then we might be able to avoid more work in bug 431204.

IMHO we should accept the current patch, if it "works" and produces "correct results", even if the patch is not the most elegant solution.

Comment 37

[Wan-Teh Chang]

Attachment: Patch v5

I made these changes.

mozilla/client.mk:

NSS_FIPS_CO_TAG is always defined and always a static tag.
This enables some simplifications.

CVSCO_FIPS_NSS is renamed CVSCO_NSS_FIPS for consistency.

mozilla/security/manager/Makefile.in: add a comment to explain
why we need to do "export" in nss/cmd/lib first.

Comment 38

[Kai Engert (:KaiE:)]

Thanks to Wan-Teh for walking with me through details of the patch, and for stepping up to do some of Nelson's improvements he agrees with.

Wan-Teh asked me to try removing the "export" and "install" steps when building in security/nss/lib, it was in fact unnecessary. I must have added that as attempts to fix the build, before I succeeded with other changes, and did not bother to try to remove them.

Wan-Teh also asked me about the exact failure when not using the other install targets. I removed them all, but then had a build failure. Building in cmd/shlibsign requires file dist/lib/libsoftokn.a

The only way I found to solve this was adding the install target.
However, I did one more full rebuild, and it turns out, running the "install" target for directory nss-fips/lib/softoken is sufficient.

Comment 39

[Kai Engert (:KaiE:)]

Attachment: Patch v6

This is based on Wan-Teh's patch, with some make targets removed (as explained in the previous comment).

Comment 40

[Kai Engert (:KaiE:)]

Attachment: Patch v7

Thanks to Wan-Teh for finding out why "install" was necessary.
He learned that when not specifying any target, there is a bug.

He asked me to try the "all" target, and indeed, then a separate make execution in the softoken directory is sufficient.

Here is a new patch that explicitly states a target in each of the new make commands.

Comment 41

[Nelson Bolyard (seldom reads bugmail)]

Wan-Teh, what bug did you find when using the default target?

Comment 42

[Wan-Teh Chang]

Attachment: Patch v8

The lib/softoken makefile bug is bug 419242.

I made some minor enhancements to Kai's patch.
1. Before we begin building each NSS, do "make clean" in
   lib/util of *the other NSS*.
2. Replace "make all" by "make libs" in the three directories
   in nss-fips because "make all" would repeat "make export".
3. In nss/lib, we don't need to specify the "all" target
   explicitly because that directory doesn't have the makefile
   bug.

This patch is about the best we can do for a simple patch.  It
has two drawbacks.
1. Every time we do "make" in security/manager, some NSS files
   will be recompiled even when they're not modified.  This is
   caused by the "make clean" steps in the lib/util directories
   of the two NSS trees.
2. In the (regular) nss tree, we will see benign warning messages
   from our makefiles like this:
     Skipping non-directory util...
     Skipping non-directory base...
     Skipping non-directory dev...
     Skipping non-directory pki...
     ...
   This is because the DIRS="util base dev pki ..." command line
   override is passed down to the submakes in each of the
   nss/lib/xxx directories.  A workaround is to use two for loops
   (in security/manager/Makefile.in) to do "make export" and
   "make libs" in these nss/lib/xxx directories.
3. The old lib/freebl/loader.c (from nss-fips) is linked with
   libssl3.so (for bypass PKCS11 mode).  So you'll be missing the
   fixes for bug 384639 and bug 400119.  Since Mozilla clients
   don't bypass PKCS11, this drawback should be irrelevant.

Comment 43

[Nelson Bolyard (seldom reads bugmail)]

The skipping non-directory issue has a simple solution.
Instead of passing in DIRS on the make command line, 
define FRANKEN_NSS on the make command line, and 
make a change similar to one of the following 

a) in nss/lib/manifest.mn 

+ifndef MOZILLA_CLIENT
 DIRS= (the old list)
+else
+DIRS= (the new list)
+endif

b) in nss/lib/Makefile

 ifndef MOZILLA_CLIENT
+DIRS := (the new list)
 ifndef NSS_USE_SYSTEM_SQLITE
 DIRS := sqlite $(DIRS)
 endif
 endif

Comment 44

[Nelson Bolyard (seldom reads bugmail)]

er, in comment 43, I realized that there's no need to define FRANKEN_NSS
because MOZILLA_CLIENT already means that. :)

Comment 45

[Nick Thomas [:nthomas] (UTC+12)]

Are the changes here for 1.8 branch only ? If not, blocking1.9? should be set so that Fx3 release drivers are in the loop.

We'll also need a tweak to the release automation for Fx & Tb if a new CO_TAG is added to client.mk

Comment 46

[Kai Engert (:KaiE:)]

Nelson, the disadvantage of your alternative you propose in comment 43 and 44 is: It would require changes to NSS. It would require a new NSS release and/or tag. We want to avoid that.

Comment 47

[Kai Engert (:KaiE:)]

(In reply to comment #45)
> Are the changes here for 1.8 branch only ? 

Yes.


> We'll also need a tweak to the release automation for Fx & Tb if a new CO_TAG
> is added to client.mk

Why?

Comment 48

[Benjamin Smedberg]

Why do we want to avoid a new NSS tag?

Comment 49

[Kai Engert (:KaiE:)]

(In reply to comment #48)
> Why do we want to avoid a new NSS tag?

Because a new NSS tag requires waiting for the next NSS release, and I assume we want a fix for FF2 as soon as possible.

Comment 50

[Benjamin Smedberg]

I do not understand... we can tag NSS now with MOZILLA_NSS_3_11_9_WITH_NSSFIPS_3_11_4, right?

Comment 51

[Kai Engert (:KaiE:)]

(In reply to comment #50)
> I do not understand... we can tag NSS now with
> MOZILLA_NSS_3_11_9_WITH_NSSFIPS_3_11_4, right?

No.

Combining those versions requires that we use copies of security/nss/lib/util.

We can obviously not use a single tag to tag two overlapping directories. That's the dilemma we are trying to solve.

The directories security/nss/lib/freebl and security/nss/lib/softoken (from 3.11.4) must get built with security/nss/lib/util from version 3.11.4

But all other directories of NSS must get built with security/nss/lib/util from 3.11.9

Comment 52

[Kai Engert (:KaiE:)]

(In reply to comment #51)
> No.
> 
> Combining those versions requires that we use 

+two

> copies of security/nss/lib/util.
> 
> We can obviously not use a single tag to tag two overlapping directories.
> That's the dilemma we are trying to solve.
> 
> The directories security/nss/lib/freebl and security/nss/lib/softoken (from
> 3.11.4) must get built with security/nss/lib/util from version 3.11.4


And that's not even sufficient.
Building the freebl and softoken directories requires many include files from other NSS directories.
We must ensure that we use the include files from 3.11.4 for building freebl/softoken.

Building in all the other directories of NSS 3.11.9 requires header files and libs from 3.11.9

Comment 53

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to comment #47)
> (In reply to comment #45)
> > Are the changes here for 1.8 branch only ? 
> Yes.

What's to prevent this problem happening with Fx3 too ?

> > We'll also need a tweak to the release automation for Fx & Tb if a new CO_TAG
> > is added to client.mk
> Why? 

Our release process sets up client.mk like this

MOZ_CO_TAG           = FIREFOX_2_0_RELEASE
NSPR_CO_TAG          = FIREFOX_2_0_RELEASE
NSS_CO_TAG           = FIREFOX_2_0_RELEASE
LDAPCSDK_CO_TAG      = FIREFOX_2_0_RELEASE
LOCALES_CO_TAG       = FIREFOX_2_0_RELEASE

so we'll need to accomodate a new tag. It's not a big deal given a bit of warning.

Comment 54

[Kai Engert (:KaiE:)]

(In reply to comment #53)
> > > Are the changes here for 1.8 branch only ? 
> > Yes.
> 
> What's to prevent this problem happening with Fx3 too ?

This bug is about finding a "workaround" at the level of Mozilla build scripts when using the NSS stable branch (3.11.x)

Firefox 3 will ship with a newer version of NSS (3.12) that is not yet FIPS approved.

Yes, at some point in the future NSS 3.12 will get FIPS approval, too.
But I hope, we are learning from this tricky issue.
I hope that a solution will be added to NSS 3.12 that will make it possible to build NSS 3.12-latest-FIPS, without requiring changes to the build scripts of client applications.


> Our release process sets up client.mk like this
> 
> MOZ_CO_TAG           = FIREFOX_2_0_RELEASE
> NSPR_CO_TAG          = FIREFOX_2_0_RELEASE
> NSS_CO_TAG           = FIREFOX_2_0_RELEASE
> LDAPCSDK_CO_TAG      = FIREFOX_2_0_RELEASE
> LOCALES_CO_TAG       = FIREFOX_2_0_RELEASE
> 
> so we'll need to accomodate a new tag. It's not a big deal given a bit of
> warning.

That's a bit unfortunate.
I had hoped changing mozilla/client.mk would be sufficient for all dependent client applications.
You are effectively telling us that the changes proposed in this bug will break other dependent products.
But you are right, it can be fixed by making similar changes to the build scripts of other dependent products.

Thanks a lot for being cooperative and your willingness to incorporate them.

Comment 55

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to comment #54)
> That's a bit unfortunate.
> I had hoped changing mozilla/client.mk would be sufficient for all dependent
> client applications.
> You are effectively telling us that the changes proposed in this bug will 
> break other dependent products.
> But you are right, it can be fixed by making similar changes to the build
> scripts of other dependent products.

Not sure I follow here, but probably gave you insufficient information in the first place. I think your changes to client.mk would affect all apps building from the 1.8 branch, since it's shared between all. The RELEASE tags are inserted after we've pulled 1.8 with a timestamp (ie using your new & old NSS tags), and created a release branch - effectively we're making a copy for that release only.

Comment 56

[Kai Engert (:KaiE:)]

Nick, thanks for the clarification.
Yes, if you want to create copies for a release branch, it would be necessary to tag that additional directory (nss-fips) as well.
This is tricky.

The proposed patch requires copies from two different tags from a single cvs directory.

This means, you can no longer use a single tag (e.g. FIREFOX_2_0_RELEASE) but will need to use two separate tags (because you can only tag a single version of mozilla/security/nss with e.g. FIREFOX_2_0_RELEASE)

For the second tag you should use the value of variable NSS_FIPS_CO_TAG, which is NSS_3_11_4_RTM.

I understand you are using the FIREFOX_2_0_RELEASE tag for creating of a release branch.

You should exclude the second copy of mozilla/security/nss from release branching, because those are read-only files by definition (must not get changed, or you lose FIPS status).

Comment 57

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 46, 
Kai, if the right thing to do is to make an NSS 3.11.10 release now,
then we should consider it.  

Comment 58

[Kai Engert (:KaiE:)]

I don't see how we would benefit from a new NSS 3.11.10 release at this point.

It would give us the chance to include the minor tweak you have proposed in comment 43, but does it really help us?

Even with that change to NSS, we'll still require the attached patch (except that DIRS variable)

Comment 59

[Wan-Teh Chang]

(In reply to comment #53)
Nick, your release process SHOULD skip NSPR_CO_TAG and NSS_CO_TAG
(because they're already static tags and contain NSPR and NSS version info)
and MUST skip the new NSS_FIPS_CO_TAG.

Comment 60

[Kai Engert (:KaiE:)]

Comment on attachment 319316 [details] [diff] [review]
Patch v8

Bob, can you please review?

I have not yet tested on Windows/Mac, maybe I should?

Comment 61

[Robert Relyea]

Comment on attachment 319316 [details] [diff] [review]
Patch v8

r+ (though I would like to see Nelson's simplified version with the subshell if it could be tested to make sure ti works on all platforms)

bob

Comment 62

[Wan-Teh Chang]

I'd like to explain why I didn't make the subshell change.
I considered that, but I found that mozilla/client.mk
doesn't use that method.  Here is an example, from
the real_fast-update makefile rule, which cd into
two directories without using subshells:
http://lxr.mozilla.org/mozilla1.8/source/client.mk#685

I thought it's better to imitate the preference of the
original author of that file.

Comment 63

[Kai Engert (:KaiE:)]

Comment on attachment 319316 [details] [diff] [review]
Patch v8

I've successfully completed a windows build. Feel free to ping me if you want to look at the binary build.

According to my inspection, the version numbers reported by freebl and softoken are 3.11.4, while the other NSS DLLs report 3.11.9

Comment 64

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 58:
> I don't see how we would benefit from a new NSS 3.11.10 release at this point.

Don't you also require Wan-Teh's fix to lib/ssl/derive.c in attachment 319405 [details] [diff] [review]?

Comment 65

[Kai Engert (:KaiE:)]

(In reply to comment #64)
> Don't you also require Wan-Teh's fix to lib/ssl/derive.c in attachment 319405 [details] [diff] [review]?

Running "export" in "security/nss/cmd/lib" seems to be a sufficient workaround.

Comment 66

[Julien Pierre]

I think we should have a better summary for this bug. If it was as simple as it says, the resolution would be fairly easy - just pick up the latest release (3.11.9). Since this bug is apparently about trying to get FF2 to pick up a hybrid version of NSS with the latest FIPS softoken, I think at the very least the word FIPS should appear in the summary.

Wan-Teh,

Re: comment 42,
The discrepancy about the loader.c is a bit worrisome. This is likely to create trouble with future NSS/softoken mixes. IMO, libssl and libsoftokn should have the same loader. Otherwise, they might try to load different libfreebl libraries, which might or might not exist. I'm not sure what the fix should be. We probably can't move this code into libnssutil3.

Comment 67

[Kai Engert (:KaiE:)]

Changing subject to "FF2 should pick up NSS fixes, but keep the FIPS approved softoken module"

Comment 68

[Kai Engert (:KaiE:)]

I'm removing the status whiteboard entry, it seems we can go a path that doesn't require a new tag
(and avoid all the tricky tweaks that delivering a single tag would require (e.g. code duplication).

Comment 69

[Samuel Sidler (old account; do not CC)]

Comment on attachment 319316 [details] [diff] [review]
Patch v8

>+NSS_FIPS_CO_TAG      = NSS_3_11_4_RTM
>+NSS_FIPS_CO_DIR      = nss-fips

Why are we moving back to 3.11.4 here? We had been using 3.11.5. What changes are not in 3.11.4 that we might rely on?

Comment 70

[Kai Engert (:KaiE:)]

{NSS 3.11.5}
  equals
{NSS-softoken from 3.11.4
 plus
 rest-of-NSS from 3.11.5}

We are not going back to 3.11.4, we are keeping the NSS component called softoken at version 3.11.4, and are upgrading the rest of NSS from 3.11.5 to 3.11.9

Comment 71

[Nelson Bolyard (seldom reads bugmail)]

I believe that the source for the softoken component in 3.11.5 was identical 
to the source for that component in 3.11.4, except for the version number.  
The softoken component was the component that was blessed by NIST for FIPS.
The version officially blessed was version 3.11.4, so PROVIDED that the 
sources for those two versions of the softoken component are identical 
(except for version number), it's better to use the blessed version.  

Comment 72

[Kai Engert (:KaiE:)]

In reply to comment 71:

$ mozcvs rdiff -u -r NSS_3_11_4_RTM -r NSS_3_11_5_RTM mozilla/security/nss/lib/util mozilla/security/nss/lib/freebl mozilla/security/nss/lib/softoken2>&1 | lsdiff
mozilla/security/nss/lib/freebl/Makefile
mozilla/security/nss/lib/freebl/nss.h
mozilla/security/nss/lib/softoken/nss.h

The change in the Makefile is a minimal build rule change.

The two new nss.h header files were added, in order to allow freebl/softoken to keep separate version numbers.

Comment 73

[Samuel Sidler (old account; do not CC)]

Assigning this to Kai so our queries show this has an owner (but if Wan-Teh should own, feel free to switch).

Comment 74

[Daniel Veditz [:dveditz]]

Two questions come up for release-drivers:

1. is there a way for us to enumerate the bugs and/or checkins that make up the diff between 3.11.5 and 3.11.9? cvs diff gives us the changes, but not really the bug numbers or comments (easily). There's got to be a branch and some date ranges we could look at in bonsai, right?

2. What sort of testing do NSS releases get, and 3.11.9 in particular? Has it already shipped in something (which would give us some comfort level since MoCo QA won't be able to test it).

Comment 75

[Nelson Bolyard (seldom reads bugmail)]

Dan, you will find all the bug numbers here
<http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=NSS&branch=NSS_3_11_BRANCH&branchtype=match&dir=mozilla%2Fsecurity%2Fnss%2Flib+mozilla%2Fsecurity%2Fnss%2Flib%2Fbase+mozilla%2Fsecurity%2Fnss%2Flib%2Fcertdb+mozilla%2Fsecurity%2Fnss%2Flib%2Fcerthigh+mozilla%2Fsecurity%2Fnss%2Flib%2Fckfw+mozilla%2Fsecurity%2Fnss%2Flib%2Fckfw%2Fbuiltins+mozilla%2Fsecurity%2Fnss%2Flib%2Fckfw%2Fcapi+mozilla%2Fsecurity%2Fnss%2Flib%2Fckfw%2Fdbm+mozilla%2Fsecurity%2Fnss%2Flib%2Fcrmf+mozilla%2Fsecurity%2Fnss%2Flib%2Fcryptohi+mozilla%2Fsecurity%2Fnss%2Flib%2Fdev+mozilla%2Fsecurity%2Fnss%2Flib%2Ffreebl+mozilla%2Fsecurity%2Fnss%2Flib%2Ffreebl%2Fecl+mozilla%2Fsecurity%2Fnss%2Flib%2Ffreebl%2Fmpi+mozilla%2Fsecurity%2Fnss%2Flib%2Fnss+mozilla%2Fsecurity%2Fnss%2Flib%2Fpk11wrap+mozilla%2Fsecurity%2Fnss%2Flib%2Fpkcs12+mozilla%2Fsecurity%2Fnss%2Flib%2Fpkcs7+mozilla%2Fsecurity%2Fnss%2Flib%2Fpki+mozilla%2Fsecurity%2Fnss%2Flib%2Fpki1+mozilla%2Fsecurity%2Fnss%2Flib%2Fsmime+mozilla%2Fsecurity%2Fnss%2Flib%2Fsoftoken+mozilla%2Fsecurity%2Fnss%2Flib%2Fssl+mozilla%2Fsecurity%2Fnss%2Flib%2Futil+&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-01-17+10%3A58%3A00&maxdate=2008-01-31+14%3A25%3A00&cvsroot=%2Fcvsroot>

Comment 76

[Robert Relyea]

I did a bit of research on redhat products, and they are either using NSS 3.11.7 (RHEL 5.1, f7, f8) or have jumped to NSS 3.12 beta (or later) (RHEL 5.2, f9).

The latter jump was precipitated by the move to firefox 3 in our products.

I don't know what sun products use 3.11.9.

The difference between 3.11.7 and 3.11.9 is about 7 months

Comment 77

[Julien Pierre]

Dan,

Sun does a lot of QA on every official release tag, on many platforms. Sun currently ships 3.11.9 as a patch for the NSS version in Solaris. The NSS testing was no different for releases 3.11.7 - 9 . Actually, a platform was added for 3.11.9, Windows AMD64, which entailed additional testing.

Comment 78

[Rob Stradling]

Thank you everyone for working on this bug. We at Comodo have been rolling out OCSP more widely over the last couple of months in preparation for Firefox 3, and as expected we have been receiving an increasing number of customer complaints (because Firefox 2.0.0.x claims that our OCSP Responder is broken).

Now, the scope of this bug at the moment is FF2.0.0.x with SSL Server Certificates.
However...

Firefox 2.0.0.x and SSL Client Certificates
Some of our customers are reporting OCSP errors when they try to do SSL Client Authentication with FF2.0.0.14, where their client certificate references our OCSP Responder.  Is this the same bug?  Will it be resolved by the same NSS upgrade fix?

Thunderbird 2.0.0.x and S/MIME Certificates
Some of our customers are reporting the same -8048 OCSP error with Thunderbird 2.0.0.14.  Could you get Thunderbird to also "pick up NSS fixes, but keep the FIPS approved softoken module" ?

Other Mozilla products
Seamonkey, Camino, etc, etc.  Do any of these use old, broken NSS versions?  If so, could they be fixed too?

Comment 79

[Samuel Sidler (old account; do not CC)]

Rob, products that are built on 1.8.1.15 will pick up the fix. That will include (for sure, pending firedrills) Firefox 2.0.0.15 and Thunderbird 2.0.0.15. If the SeaMonkey and Camino teams also build a release off of 1.8.1.15, it will pick up this fix. I can't speak for SeaMonkey, but I know Camino intends to release off of 1.8.1.15. For all other products, you should contact the project leads and ask them to create a new release on the same schedule as 1.8.1.15, if they aren't already working on one.

Comment 80

[Daniel Veditz [:dveditz]]

Comment on attachment 319316 [details] [diff] [review]
Patch v8

Approved for 1.8.1.15, a=dveditz for release-drivers

Nelson, rrelyea, julien: thanks for the answers in comments 75-77. Kai: thanks very much for the patch to make this approach possible.

Comment 81

[Kai Engert (:KaiE:)]

(In reply to comment #80)
> Kai: thanks very much for the patch to make this approach possible.

I'd also like to thank Wan-Teh very much for his great support and help in getting this done.

Comment 82

[Kai Engert (:KaiE:)]

Checked in to 1.8 branch for 1.8.1.15 / Firefox 2.0.0.15

Comment 83

[Kai Engert (:KaiE:)]

Wan-Teh, I realize, when NSS 3.11.9 got released, it was combined with NSPR 4.7

Right now this Mozilla 1.8 branch uses NSPR 4.6.8
Do you see a need for us to upgrade to NSPR 4.7 or even 4.7.1 ?

Comment 84

[Wan-Teh Chang]

I recommend that you upgrade to NSPR 4.7, but it may not be
absolutely necessary.  The only thing NSS 3.11.9 needs from
NSPR 4.7 is the WIN64 port, but Firefox 2.0.0.x doesn't need
the WIN64 port.

Comment 85

[[e-mail] (:bhearsum)]

I noticed this in the build logs while doing the 2.0.0.15 release:
ind: /Developer/SDKs/MacOSX10.2.8.sdk/Library/Frameworks: No such file or directory
find: /Developer/SDKs/MacOSX10.2.8.sdk/Library/Frameworks: No such file or directory
rm -rf /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/nss/libnss.a /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/nss/libnss3.dylib  /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/nss/nssinit.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/nss/nssver.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/nss LOGS TAGS /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/nss/.md core           so_locations _gen _jmc _jri _jni _stubs  
Thu Jun 12 04:04:47 PDT 2008
cd ssl; /usr/bin/make -j1 clean
find: /Developer/SDKs/MacOSX10.2.8.sdk/Library/Frameworks: No such file or directory
rm -rf /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/libssl.a /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/libssl3.dylib  /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/derive.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/prelib.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/ssl3con.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/ssl3gthr.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/sslauth.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/sslcon.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/ssldef.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/sslenum.o /builds/tinderbox/Fx-Mozilla1.8-
 Nightly/Da
rwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/sslerr.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/sslgathr.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/sslmutex.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/sslnonce.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/sslreveal.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/sslsecur.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/sslsnce.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/sslsock.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/ssltrace.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/sslver.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/
 nss/ssl/au
thcert.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/cmpcert.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/nsskea.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/sslinfo.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/ssl3ecc.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/unix_err.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl LOGS TAGS /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/ssl/.md core           so_locations _gen _jmc _jri _jni _stubs  
Thu Jun 12 04:04:47 PDT 2008
cd pkcs12; /usr/bin/make -j1 clean
find: /Developer/SDKs/MacOSX10.2.8.sdk/Library/Frameworks: No such file or directory
rm -rf /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs12/libpkcs12.a /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs12/p12local.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs12/p12creat.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs12/p12plcy.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs12/p12tmpl.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs12/p12e.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs12/p12d.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs12 LOGS TAGS /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs12/.md core           so_locations _gen _jmc _jri _jni _stubs  
Thu Jun 12 04:04:47 PDT 2008
cd pkcs7; /usr/bin/make -j1 clean
find: /Developer/SDKs/MacOSX10.2.8.sdk/Library/Frameworks: No such file or directory
rm -rf /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs7/libpkcs7.a /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs7/certread.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs7/p7common.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs7/p7create.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs7/p7decode.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs7/p7encode.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs7/p7local.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs7/secmime.o /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs7 LOGS TAGS /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/pkcs7/.md core         
   so_locat


and further down:


/builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/nss/nsinstall -L `pwd` -m 444 secutil.h NSPRerrs.h SECerrs.h SSLerrs.h /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/dist/private/nss
/usr/bin/make -C /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/mozilla/security/nss/lib MAKE="/usr/bin/make -j1" -j1 CC="gcc-3.3 -arch ppc" MOZILLA_INCLUDES=-I/builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/dist/include/dbm SOURCE_MD_DIR=/builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/dist DIST=/builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/dist NSPR_INCLUDE_DIR=/builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/dist/include/nspr NSPR_LIB_DIR=/builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc/dist/lib MOZILLA_CLIENT=1 NO_MDUPDATE=1 NSS_ENABLE_ECC=1 BUILD_TREE=/builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/build/unifox/ppc BUILD_OPT=1 NS_USE_GCC=1 NS_USE_NATIVE= NSDISTMODE=absolute_symlink MACOS_SDK_DIR=/Developer/SDKs/MacOSX10.2.8.sdk DIRS="util base dev pki pki1 certdb certhigh pk11wrap cryptohi nss ssl pkcs12 
 pkcs7 smim
e crmf jar ckfw ckfw/builtins"
find: /Developer/SDKs/MacOSX10.2.8.sdk/Library/Frameworks: No such file or directory
make[5]: warning: -jN forced in submake: disabling jobserver mode.
cd util; /usr/bin/make -j1 export
find: /Developer/SDKs/MacOSX10.2.8.sdk/Library/Frameworks: No such file or directory
Skipping non-directory util...
Thu Jun 12 04:08:09 PDT 2008
Skipping non-directory base...
Thu Jun 12 04:08:09 PDT 2008
Skipping non-directory dev...
Thu Jun 12 04:08:09 PDT 2008
Skipping non-directory pki...
Thu Jun 12 04:08:09 PDT 2008


and it continues further down..here's the full log:
http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla1.8/1213266840.1213273516.11180.gz

These started appearing in the nightly logs after this change was landed. Here's the nightly log for the 23rd:
http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla1.8/1211539020.1211545279.27445.gz&fulltext=1
and for the 24th:
http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla1.8/1211625240.1211631550.16801.gz&fulltext=1


Do we need to halt 2.0.0.15 for this?

Comment 86

[[e-mail] (:bhearsum)]

ss points out that comment # 42 addresses this. Sorry for the noise!

Comment 87

[Wan-Teh Chang]

I thought you're complaining about this:

find: /Developer/SDKs/MacOSX10.2.8.sdk/Library/Frameworks: No such file or
directory

Comment 88

[[e-mail] (:bhearsum)]

Hm, that's worth investigation too. I'm going to try to see when it first appeared.

Comment 89

[[e-mail] (:bhearsum)]

So, build logs from May 16th have it in them too, definitely unrelated to this.

Comment 90

[Nelson Bolyard (seldom reads bugmail)]

Is this bug resolved now?
Has a release of FF2 finally been shipped that contains the fix for the 
OCSP problems that were the original subject of this bug?
If so, can this bug be resolved?
If not, what needs to be done to get those OCSP fixes shipped in FF2?

Comment 91

[Rob Stradling]

It looks to be fixed to me.  :-)

I just installed Firefox 2.0.0.14 on WinXP, then enabled OCSP checking, then browsed to https://ocsptest.comodoca.com. As expected, I got the -8048 error.
Then I clicked "Help->Check for Updates..." and let Firefox update itself to 2.0.0.15. Then I could successfully browse to https://ocsptest.comodoca.com without any errors.  :-)

Thank you everyone.

Comment 92

[Kai Engert (:KaiE:)]

marking as verified1.8.1.15

Although no action is planned for >= firefox 3 at this time, I'm resolving this as fixed.