Closed Bug 171331 Opened 22 years ago Closed 22 years ago

Thawte Freemail certificates not trusted

Categories

(MailNews Core :: Security: S/MIME, defect, P1)

Product:
MailNews Core
Component:
Security: S/MIME
Version:
Other Branch
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
psm2.4

People

(Reporter: bah_pop3, Assigned: KaiE)

References

Details

(Keywords: regression)

Attachments

(10 files, 2 obsolete files)

Screen dump of main cert mgr screen.
16.63 KB, image/png
Details
Screen dump of cert viewer for one cert.
19.11 KB, image/png
Details
Screen dump of main cert mgr screen
16.29 KB, image/png
Details
Screen dump of Builtin Object Token for Thawte Personal Freemail CA
18.85 KB, image/png
Details
Patched Generated file.
66.92 KB, patch
Details | Diff | Splinter Review
Patch so addbuiltins generate corrrect Serial numbers
784 bytes, patch
Details | Diff | Splinter Review
Updated old serial number acceptance patch that doesn't break sensitive platforms.
1.68 KB, patch
Details | Diff | Splinter Review
program to check trust on built-ins
7.58 KB, patch
Details | Diff | Splinter Review
Patch v2 to certdata.txt
38.58 KB, patch
KaiE
: review+
blizzard
: approval+
Details | Diff | Splinter Review
Patch for 1.2 branch
109.38 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20020927
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20020927

Trying to send e-mail signed with a Thawte Freemail cert produces a send message
error:

'Sending of message failed.
'Unable to sign message.  Please check that the certificates specified in Mail &
Newsgroups Account Settings for this account are valid and trusted.'

I first saw this 2002092617; things were fine with 20020924.  Looking at the
certs for my accounts, it seemed that several certs were missing.

Up-dating to today's build, the problem persisted.  I re-imported my certs (from
back-up).

The Certificate Manager indicates '<Issuer Not Trusted>' for each of my certs;
ditto for the Thawte Freemail certs of others (under the second tab).

I'm assuming that this is related to the recent NSS changes.  At any rate, it
seems unrelated to the various bugs involving certificates, signing, and Thawte
that I looked at before filing this (I've actually avoided filing bugs up till
this point).

I'm tentatively assigning a severity of Major, in as much as S/MIME is a
day-to-day feature for many users, and the problem (whatever its source) is
preventing normal S/MIME functionality.

Reproducible: Always

Steps to Reproduce:
1.  Write an S/MIME e-mail using a Thawte Freemail cert.
2.  Try to send the signed e-mail.

Actual Results:  
A Send Message Error was produced.

Expected Results:  
That Mozilla would prompt me for my password for the Software Security Device
and then send the e-mail as per usual.
What is the expiration date on your thawte freemail RSA CA certificate.  there
are two certificates that are identical in every way, except expiration date. 
This can cause some problems (Thawte's fault - poor policy in this case).  One
expires in 2002, and the other in 2004.

Also, have you tried a new profile to see if that makes any difference, or are
you performing all of these operations from within the same profile?
Expiration dates of my certs vary between 4 April 2003 and 9 August 2003.  I
have since retrograded to 2002091808, and they're fine.  As I originally
indicated, all Thawte certs, others as well as mine, showed '<Issuer Not
Trusted>'; those of others now indicate 'Sign,Encrypt'.

I was experiencing other, apparently unrelated problems with my profile (the
truncated 25 Sept build ended up corrupting an attempt to re-install the
functioning 24 Sept build); if you wish details of that, I can probably still
provide them.

I ended up reverting to the 18 Sept build, using a clean profile, and all seems
well.

The only other thing I noticed was that, with the 26/27 Sept builds, not all of
my certs were being read (originally noted looking under Edit | Mail &
Newsgroups Account Settings | [account] | Security -- Select), so there were
some accounts for which there /was/ no valid cert at the time; however, the
behaviour first manifested itself to me with an account for which there /was/ a
cert.

Importing the certs again didn't clarify the problem; it was then that I looked
at the entries in the Certificate Manager and noted the '<Issuer Not Trusted>'.

Hope this clarifies matters somewhat.
Just tried this again with 2002100108 with the same effect I'd previously noted.
 Reverted to 2002092506 and all seems well.
reporter please restate which problem you're still seeing. It there's another
problem can you open a different bug. Let's not morph bugs.

Julien, wtc, is there a date in this that corresponds to either Root ca work or
update in the version of NSS? (around 9/25?)
Assignee: ssaux → kaie
The NSS used by PSM was upgraded from 3.5.1 Beta
to 3.6 Beta on Thursday, 2002-09-26. So the
2002-09-26 Mozilla trunk daily build is the first
one using NSS 3.6 Beta.

You can verify the NSS version number by looking
for nss3.dll in the Mozilla installation directory,
opening it up for "Properties", and selecting the
"Version" tab.

In any case, this looks like a bug introduced by
the NSS 3.6 Beta upgrade.
In re. comment #4:

Er, sorry.  Wasn't meaning to morph the bug.

Simply, what I've seen is:

1.  I cannot send send a signed e-mail and get the following message when I try:
'Sending of message failed.
'Unable to sign message.  Please check that the certificates specified in Mail &
Newsgroups Account Settings for this account are valid and trusted.'

2.  The Certificate Manager indicates '<Issuer Not Trusted>' for each of my
certs; ditto for the Thawte Freemail certs of others (under the second tab).  No
other CA seems to be affected.

3.  I don't know what might happen if I received a mail signed with such a cert.

4.  Other issues involved in retrograding are, as you suggest, probably unrelated.

Hope this helps clarify. . . .
Brian, I think you did not answer the question in comment, which is very important:

  What is the expiration date on your thawte freemail RSA CA certificate?

If possible, you could also make a screenshot the window shown when doing "view
cert" the thawte freemail ca certificate.

It's not unlikely that I didn't directly answer the question since I have
serveral certs.  I'll just attach a screen shot of the cert mgr; the dates are
there.  Will also, as requested, attach a screen shot of one of the certs. --
Will try to grab a new build later today and will do the same with that.
Screen shot indicating the expiry dates of my various Thawte Freemail certs.
Brian: I wanted to see something else. Please go to cert manager, find the thawte
freemail ca, click view cert, make a screenshot of the dialog that is shown now
- which shows information about the CA cert.

But now I'm confused. You said your certs are listed as <issuer not trusted>.
However, in the screenshot you just attached, your certs are listed as valid.

Screen shot of Certificate Viewer for one cert using 1.2a.
In re. comment #7:  Sorry for any confusion I might have caused.  Hopefully the
subsequent screen shots, using today's build, will help clarify.

BTW, could you clarify 'Please go to cert manager, find the thawte freemail ca,
click view cert, make a screenshot of the dialog that is shown now - which shows
information about the CA cert'? -- I assume you mean the Builtin Object Token,
but am not sure.
As opposed to attachment 101987 [details], this is what the main certificate manager
screen looks like using 2002100704.  Certs -- my own presumably valid certs --
are broken.  (I assume there's no need to attach screen shots of those details.
. . .)
Kai:  I assume this is the info you requested; my apologies if not.
Brian: ok, that's the info I wanted to see. So in general your certificate seems
to be valid.

But now let's check whether your certificate database has marked that CA
certificate as trusted.

Go to cert manager and open the Authorities tab. Again find the Thawte Personal
Freemail CA cert and select it. Now click the "edit" button. Is the checkbox
saying "trust for email certificates" checked? It should be checked.

Kaie, here's another data point, Netscape 7.0 with NSS 3.6 Beta3 correctly
handles my Thawte FreeMail certs.

One thing that might help debug things would be to take a copy of Brian's
cert7.db and try to import one of our own Thawte certs into it and see what
happens. At this point it looks like there is something about his database that
is causing the sensitivity. Though I'm at a loss to figure out what it could be.
His dialogs don't indicate anything out of the ordinary. My guess is there is
something funny in his database that NSS 3.5 was ignoring and NSS 3.6 trips over.

bob

BTW brian, it's only the cert7.db that we should look at. Your keys are stored
in key3.db, so you definately don't want to copy that file around the internet.

bob
Umm . . . so you wish me to attach my cert7.db?  Please confirm. . . .

Kai:  the CA certificate trust settings for Thawte Personal Freemail CA indicate
'This certificate can identify mail users' (the second check-box) . . . but
that's not precisely what you asked for.

Note that this is with the 2002091014 build (that seems to be about the only one
to which I can easily revert, and even then have to delete compreg.dat to get it
to lauch . . . ). -- I'll try to check with a newer build either later tonight
or tomorrow. . . .
OK, with 2002100704, that second box ('This certificate can identify mail
users.') is *not* ticked.

Am I then to assume that this is due to '<Issuer Not Trusted>' (as in
<http://bugzilla.mozilla.org/attachment.cgi?id=101991&action=view>)?
I just downloaded 20020100704 and confirmed that I could read my Thawte certs,
so it's something in the environment, Brian, how big is your database? if it's
too big to attach, or you don't feel comfortable attaching it, I could send you
a signed message and you can email it to me encrypted. 

bob
The database is 92 kb in size.  Yes, you guessed correctly:  I don't feel
entirely comfortable attaching it to the bug.  You can send me an e-mail at
<humbug@myrealboxXXX.com> (/sans/ the obvious munging) and I'll forward a copy
of it to you.  I suppose in the end it doesn't matter /that/ much, but still. . . .
Brian,

I also have a Thawte freemail cert and I tried your steps #6 - everything worked
fine for me.

Here is what I suggest :

1) Save your certs to a p12 file using the backup function.
2) create a new profile in mozilla. This means it will have its own new
cert7/key3 databases
3) import the p12 file
4) see if the cert is still untrusted in PSM and if you can't sign emails with it


OK, The problem is that Brian's Database has the "Thawte Basic CA" and the
"Thawte Freemail CA" loaded in the database untrusted.

Unfortunately it's very difficult to see that a Certificate is in both the
Internal Database and the builtins, so there is no UI from PSM with which to
delete the offending certificates. Kaie, we need to figure out how to fix this.

There is a mystery about why it worked in previous releases. This seems like an
issue we should check for in our test suites. We shouldn't trust certs that are
explicitly not trusted in our database, but are trusted in the built-ins modules.

Anyway the code is currently working the way it supposed to. Brian, you can fix
your problem in one of two ways:

1) use PSM to explicitly add 'email' to your "Thawte Personal Freemail CA" and
"Thawte Personal Basic CA". This change will cause those Thawte certs to be
trusted no matter what happens to the builtin's module.

2) use certutil to remove these two certs from your certdb:
  1. Download the NSS binary release.
  2. add {nssrelease}\bin and {nssrelease}\lib to your path.
  3. run certutil -L -d {your_Netscape_7_profile_dir}
  4. run certutil -D "name_of_Personal_freemail_ca" -d {your_Netscape_7_profile_dir}
  5. run certutil -D "name_of_Personal_freemail_ca" -d {your_Netscape_7_profile_dir}
   This will restore your database to it's prestine order.

1)obviously much is simpler than 2). We need a way to do 2) easily from PSM.


I also ran into this problem on my home system running OS/2 when I moved to NSS
3.6 , but the office installation of Mozilla 1.2alpha was unaffected.
Thanks, Robert.  As you point out, the first solution is much easier than the
second; I will check that out with the next nightly I download.

For future reference:  Would Julien Pierre's suggestion (exporting then
importing in to a new profile) help alleviate matters in any way?

I'm still baffled as to why it is the change in NSS that triggers the problem;
if I revert to an older build (2002092308 right now), all seems well, even tho'
the problem with the database would still be there, no?

FYI, I came across
<news://news.mozilla.org:119/anv1lp$m1a3@ripley.netscape.com>, which sounds
somewhat similar to what I experienced.
I think I don't understand the problem.


> OK, The problem is that Brian's Database has the "Thawte Basic CA" and the
> "Thawte Freemail CA" loaded in the database untrusted.

Untrusted in both?
I thought
- the builtin never can have its original trust changed
- an additional copy stored in the database stores the trust and always
overrides the builtin


> Unfortunately it's very difficult to see that a Certificate is in both the
> Internal Database and the builtins, so there is no UI from PSM with which to
> delete the offending certificates. Kaie, we need to figure out how to fix this.

I thought we don't need to do this, because the copy in the database is supposed
to override the builtin?


> There is a mystery about why it worked in previous releases. This seems like an
> issue we should check for in our test suites. We shouldn't trust certs that are
> explicitly not trusted in our database, but are trusted in the built-ins modules.

Agreed, that's what I assumed how it would behave, based on the overriding theory.


> Anyway the code is currently working the way it supposed to. Brian, you can fix
> your problem in one of two ways:
>
> 1) use PSM to explicitly add 'email' to your "Thawte Personal Freemail CA" and
> "Thawte Personal Basic CA". This change will cause those Thawte certs to be
> trusted no matter what happens to the builtin's module.

Are you now confirming that indeed the copy in the database will override the
trust in the builtin?


> 2) use certutil to remove these two certs from your certdb:
> 1)obviously much is simpler than 2). We need a way to do 2) easily from PSM.

If you say 1) is sufficient, why do we need to support 2) in PSM?
Please let me try to summarize, and correct me if I'm wrong:

Brian has a database where the database copy of the Thawte Freemail CA is not
trusted for Email Signing.

The screenshot from comment 14 confirms the cert is not trusted.

Brian says, with recent versions of Mozilla, some people's certificates are not
trusted.

Brian also says, going back to an older version of Mozilla, using the same
computer system, using the same profile, the same certificates are now trusted.

Can you confirm?


If you can confirm, I'd be interested to hear: In the old version of Mozilla,
where email works fine and certificates are trusted, what email trust setting is
shown for the Thate Freemail CA?

I.e., in comment 19 you say, the recent build has the box *not* ticked.

Is it ticked in the older working version?

No, reimporting certs will not automatically set the trust on the root most
certificate. I know some NSS applications will try to verify the cert after
import and then try to look up the root most cert and ask the user if they wish
to explictly trust it. 

The previous build behavior bothers me. I don't know why the certs show up
trusted when the shouldn't have been (the local database is supposed to override
the builtins, so users can explicity remove trust from certs if they want to).

bob
I've not yet figured out how to reply to a Bugzilla comment, so you'll have to
bear with me, I'm afraid.  This is in response to comment 27.

1.  I posted the link to the news article simply to indicate that the problem
may not be unique to me (altho' Julien Pierre had suggested that he'd had a
similar problem).

2.  I am seeing this simply by moving back and forth between newer and older
versions of Mozilla, and first noticed the problem with the 26 Sept build.  In a
couple of instances, I've cobbled together a new profile, but the contents of
cert7.db have been the same.  Note that shortly after I first noticed this I did
import my certs from a back-up but without deleting the existing cert7.db.

3.  In older bulds (currently 2002092308), 'This certificate can identify mail
users' *is* ticked.
I have the same problem with Build IDs 2002101612 and 2002101704 under Windwos
2000, Service Pack 2. 
I have a certificate from Keytrust (www.keytrust.de; german only, sorry) to sign
and encrypt my e-mails. It worked well with Mozilla 1.2alpha (2002091014).
In 2002101612 and above, the PSM says '<Issuer Unknown>'.
The certificates is valid until 5.11.2002, the CA certificates until 2005.

Deleting key3.db and cert7.db and re-importing all certificates didn't change
anything. My certificate stays unverified and signing e-mails still fails.

If it helps, I can send you/attach my cert7.db
Confirming, since Bob was able to see problems in the cert db. Marking as
regression.

This bug sounds like it can give us lot of trouble with future releases.

I don't understand whether it is the real reason, but if certificate databases
from older builds are common to have damaged trust settings, then we might
likely see a lot of problem reports once this new behaviour goes out.

I think Brian's statement in comment 29 is important.
He says, with an older build, he indeed sees the CA is marked trusted for
issueing email certs.
Simply switching the build from old to new makes the checkbox go away, and going
back to an older build makes it come back again.

I conclude there must be some information stored in the certificate database we
could use to detect this special situation and automatically correct the situation?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta1+, regression
Matthias, re comment 30, I think your problem might be a different bug. You say
the issuer is unknown. This should mean the issuer certificate is absent, while
this bug is about incorrect trust assigned to the issuer certificate. Please
check whether you indeed have the issuer certificate. View the cert and look at
details, and check whether there is a chain of certs listed or only one cert. If
there is only one cert, please try to reproduce twice with a new profile, both
with the current and with an older build. If you see a difference between the
builds, please file a separate bug. Thanks!
Depends on: 175085
Priority: -- → P1
Target Milestone: --- → 2.4
Matthias, I think what you are seeing is my bug 173939. 
See especially bug 173939 comment 10.
I can now confirm both Brian's and Matthias's problems.

With the 10162002 build, I have everything checked for the lab212 CA Certificate
and yet only client auth appears as the extension it is trusted for.

My Thawte Freemail RSA certificate is displaying as not trusted, even though the
Thawte Freemail CA certificate is marked trusted for all authentication types.

I believe all of these bugs are related to bug 173939.
Just to confirm that at least the first of the fixes/work-arounds Robert Relyea
gave in comment #23 (/i.e./, manually ticking 'This certificate can identify
mail users' for both Thawte Personal Freemail CA and Thawte Personal Basic CA)
works.

I was waiting for a slightly more stable build before trying it, but it worked
with 1.2b (2002101608) and persisted when I then installed 2002101708.  So it
would seem that my problems are in fact solved.

The comments to which Torben points in comment #33,
<http://bugzilla.mozilla.org/show_bug.cgi?id=173939#c10>, suggest that the
problems I encountered are similar to those that he has encountered and,
presumably, to those Matthias (in comment #30) has encountered.
What is confusing me is how the databases get into this state, and why older
builds are happy with the database, and why I haven't been able to reproduce it
with the same CA?

I've included ian on the CC list, Ian do you know if there was any changes to
the pki trust generation code that could cause this?

The only other thing I can think of is the certs are really in the database with
'trust unknown' but 3.6 is treating that as 'untrusted'.

bob


Bob-

I looked at diffs with NSS 3.5, and the only changes to the trust lookup code
are the ones you made to compute the SHA-1 fingerprint of the cert.  Perhaps the
wrong value is being returned?

Other than that, there were no changes.
I cleaned my system and using the 20021021 build, I cannot reproduce the problem
again.

Other than errors I see when looking at the capabilities for the Freemail RSA in
the view certificate screen, I am not getting the disappearing checkbox any
longer when switching from moz 1.1 to moz1.2b

I do notice that the root CA (Thawte Freemail CA) is a builtin, whereas the
issuing CA (Thawte Freemail RSA) is on the software security device.  Most of
the issues that I am seeing relate to CAs that are on the SSD, not the builtins.

I still continue to see bug 173939 however.
*** Bug 175715 has been marked as a duplicate of this bug. ***
Bug 173939 will be fixed with an upgrade of NSS (see bug 174634). Can someone
test if this also fixes this bug, details are in bug 173939 comment 36
I am now able to reproduce this bug, too. Not with Thawte certs, but with our
production corporate intranet certificates. The GET cybertrust root is not
trusted with a build since about 1.2 beta, and is trusted again if I go back to
1.2 alpha.

My cert database is the primary one I had been always using during the last months.

I'm proposing to raise this bug into a Mozilla 1.2 release blocker.
Severity: major → critical
Status: NEW → ASSIGNED
Keywords: mozilla1.2
OK, I have a handle on this now. The good news is that it is indeed a regression
in NSS 3.6, so we don't have Mozilla 1.0 and 1.1 creating trashed certificate
databases. I'll attach a patch tomorrow. The fix is in the built-ins.

The general problem is the perrenial bug we have had in NSS where we incorrectly
set the PKCS #11 serial number to the ANS.1 decoded serial number (not the
encoded serial number). NSS 3.6 fixed most of these occurances, but did not fix
the built-ins. This works for everything except the case where the given
certificate is in the certdb in an unknown trust state and in the builtins in a
known trust state. The internal db will report a correct issuer/SN for the
certificate, which will then not be found in the built-ins.

bob
NOTE: This patch needs careful review of the following:

All instances of CKA_SERIAL_NUMBER needs to change from the previous form of:
{data}
to the new form of:
Int Tag; length; {data}

Int Tag is octal 002
Length is the length of data in bytes (expressed as an octal number)
Data is the exact literal data passed in.

The line length is 16 bytes, so  for many of the Serial numbers the lines
will break in different places.

The change is straightforward and mechanical, but there are a lot of certs and
making sure each is correct is critical.
This file is mechanically generated from certdata.txt. If certdata.txt is
correct, this file should also be correct.
This program only gets compiled by hand when we want to add a new builtin root.
I've checked these into the NSS 3.7 tip. Before I check them into the 3.6
branch, I would like to have the following:
1) a couple of people review the certdata.txt changes to make sure everything is
within the parameters I described.
2) Kaie, could you check that the builtins built with this patch will not
regress 3.5 when installed.

If I get these two things, I can check this fix into 3.6 so we can get approval
to put it in 3.7.

bob
Comment on attachment 104639 [details] [diff] [review]
Patch ot accept old Serial numbers so the builtins work against older versions of NSS.

This patch breaks the build on some platforms (bug 171331).
Attachment #104639 - Flags: needs-work+
Comment on attachment 104638 [details] [diff] [review]
Patch to certdata to turn all the decoded Serial numbers into encoded Serial numbers

We should use a program or script to
doublecheck the changes to certdata.txt.
*** Bug 177352 has been marked as a duplicate of this bug. ***
Some first comments:

The patch to bfind does apply on the 3_6 branch, but it does not apply to the
current client tag (I didn't try to merge yet).

The patch to addbuiltins applies to both 3_6 branch and the client tag.

The patches to certdata.* do neither apply to the 3_6 branch nor the client tag.
I assume you already made more changes to the list of CA certs on the tip of NSS?


I think I'll hack a script to produce the patch for certdata.txt file that applies.


Since we will be moving the client tag to new revisions on the 3_6 branch, I
suggest I'll test with that branch.

checkbuiltins.c

This is a test program to automatically check the trust in the root certs in
the  root cert module. It returns 0 upon success and 1 upon failure.

It requires the tool "rm" to be in the environment in order to delete the
existing databases. This could be changes to be done from above in a script,
but this is a must for the tool to run correctly, so for now it is done in the
C program through the C function "system".

It also requires the root cert module to be in the current directory in order
to load it.
Depends on: 177798
I added a dependency on bug 177798 because the checkbuiltins program does a
shutdown and restart of nss . The fix is required to run checkbuiltins , not to
fix this bug . However, I think we want to integrate checkbuiltins into our
automated QA so this type of error gets picked up quickly.


Hey Bob, you intentionally left out exactly one change, to test whether we
really would review it, right? ;-)

My automated review, using a script that auomates doing the change, shows that
you left out one serial number in the patch and in the NSS trunk checkin.
Go to line 5652 in certdata.txt and you'll find a serial number that is listed
as "\001".

In comment 52 I said your patch to certdata.txt would neither apply to the
3_6_branch nor to the current client tag.
Well, that general statement was wrong - only the first hunk does not apply,
which changes the CVS comment - everything else applies.

However, since one serial number change is missing, I'm adding a new patch, and
I'm marking it also as reviewed - I think it reasonable to mark it as reviewed,
since my script produced a patch that only differs in this single additional
change from your patch.
Here is the mentioned change that is required on the tip of NSS:

Index: certdata.txt
===================================================================
RCS file: /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v
retrieving revision 1.26
diff -u -r1.26 certdata.txt
--- certdata.txt        30 Oct 2002 17:09:28 -0000      1.26
+++ certdata.txt        1 Nov 2002 11:40:00 -0000
@@ -5649,7 +5649,7 @@
 \144\040\103\101\040\122\157\157\164
 END
 CKA_SERIAL_NUMBER MULTILINE_OCTAL
-\001
+\002\001\001
 END
 CKA_VALUE MULTILINE_OCTAL
 \060\202\004\036\060\202\003\006\240\003\002\001\002\002\001\001

This patch
- applies to certdata.txt on the NSS_3_6_BRANCH
- does not change the CVS comment as the previous patch did
  (shouldn't matter, automatic change done by cvs)
- includes the additional serial number change shown in my previous comment

Everything else is identical to Bob's patch, I diffed the patches.
Attachment #104638 - Attachment is obsolete: true
Comment on attachment 104846 [details] [diff] [review]
Patch v2 to certdata.txt

r=kaie as explained
Attachment #104846 - Flags: review+
Hmm, Bob I see that you already checked in your changes to the NSS_3_6_BRANCH,
too - so we should make the additional changes (.txt and .c) mentioned in
comment 56 to both the tip and that branch.

I believe you still want me to do test 2) from your comment 47.

If I understand you correctly, you want me to use a version of Mozilla/PSM that
uses NSS 3.5, like Mozilla 1.0.1 or Netscape 7, and make it use the nssckbi from
the NSS_3_6_BRANCH including your patches.

I'll test that now and comment here.

For all tests I hid the nssckbi file (moved it) that is referenced in my secmod.db
(just to be safe, because it points to my compilation directory).


Ensure I still can reproduce the bug
====================================
I retested again using the backup of the profile that I can use to reproduce
this bug.

1.0.1, 1.1, 1.2a: work as expected
1.2b (without the patch) fails as expected


Test whether the patches from this bug fix the problem
======================================================
I compiled NSS from the 3.6 branch.
I only used one file from this build.
I replaced the nssckbi in the Mozilla 1.2b release with the nssckbi from the
test build.

Good news: The patched 1.2b installation works!
So I can confirm that the patches in this bug fix the problem. Thanks Bob!


Test whether the patches from this bug cause a regression for older builds
==========================================================================
I replaced the nssckbi in the Mozilla 1.0.1 release with the nssckbi from the
test build.
I tested reading several signed S/Mime messages, both trusted and untrusted
signatures,
and I visited several https sites, both trusted and untrusted.
The trust was exactly as I expected it to be.
So I can not spot any regressions. Please let me know if you have suggestions
for further regression tests.
Good catch Kaie, I have much more confidence now that both you and Julian tested
the patch. I'm not sure why Julian's program missed the serial number though.

We're going to patch up the his test case and include it in our all.sh suite for
NSS (so it will get ran nightly).

Wan-Teh is on vacation and 1.2 has branched, so it's up to you and I to get this
into the mozilla tree, do you know the process?

We should patch all these changes together. Julian as a shutdown/restart patch
as well. (another nice side effect of his program -- it tests
init-shutdown-init-shutdown sequence.)

bob
Blocks: 1.2
I have started the process to get this fix and its blocker 177798 into Mozilla
1.2 by nominating them in the "make 1.2 not suck" tracking bug 174647. I have
also sent mail to drivers asking for approval.

*** Bug 176615 has been marked as a duplicate of this bug. ***
Comment on attachment 104846 [details] [diff] [review]
Patch v2 to certdata.txt

a=blizzard on behalf of drivers for 1.2 final.

Please try to get this in before the tree closure on the morning of Nov 5th,
2002 or you will have to wait until after we finish making the 1.2 branch.
Attachment #104846 - Flags: approval+
Please note that this problem also occurs on Linux 2.4 (Redhat 8.0).


This is a single patch file that combines all the changes required for the 1.2
branch.
It contains the new certdata.txt, including the missing serial number, the
changes to bfind.c and addbuiltins.c and the certdata.c file generated from
certdata.txt.
I will check it in to the 1.2 branch now.
The patch for the 1.2 branch has been check in to MOZILLA_1_2_BRANCH.
(I would have marked this bug with the fixed1.2 keyword, but there is not yet
such a thing.)
Builds from the 1.2 branch downloaded tomorrow, as well as the final 1.2 release
will have this bug fixed.

The bug is not yet fixed on the Mozilla trunk builds. If you use the nightly
trunk builds, you will have to wait some more, until the NSS_CLIENT_TAG gets
moved in a couple of days, after the release of NSS 3.6.1.
Because of that, I'm not marking this bug as fixed.
No longer blocks: 1.2
The nss3.dll file from my last trunk nightly (2002111810 I think) says it is
version 3.6.1 Beta. That should mean this is fixed?
yes it should be fixed in the tip now.
Marking as resolved fixed.  for those of you encountering the problem, please
pick up a recent build and verify that the issue has been corrected via comments
in this bug.

thanks,
Charles
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Verified then.
Status: RESOLVED → VERIFIED
*** Bug 143904 has been marked as a duplicate of this bug. ***
Product: PSM → Core
Product: Core → MailNews Core
QA Contact: carosendahl → s.mime
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: