Closed Bug 39468 Opened 24 years ago Closed 18 years ago

Able to corrupt cert7.db

Categories

(NSS :: Libraries, defect, P2)

x86
Windows 95
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: bugzilla, Assigned: rrelyea)

References

Details

This is a replacement for the internal Netscape bug
http://scopus/bugsplat/show_bug.cgi?id=77005 .  The gist of the previous report
is:

  Here's the steps to corrupt cert7.db:

  1. I fetched the cert for lord@netscape.com from ldap (serial #51)
  2. I opened an email signed with a newer cert for lord, serial #04:F7. This 
  step over-writes the cert for lord@netscape.com in cert7.db.
  3. I search for lord@netscape.com in ldap again. It says it finds one, then  
when 
  I view lord@netscape.com, I still see #04:F7...so far so good.
  4. I delete lord@netscape.com's cert. It asks if I want to delete #04:F7, I 
  confirm, and it deletes it.
  5. lord@netscape.com still shows up in the list, but I can't view, delete, or 
  verify this entry.  Database is corrupt.  Bummer.

  -cdn

The solution to this bug will come with replacing the existing permanent cert db
with a pkcs#11 module; when that is done we should confirm that related data is
stored properly and the above sequence of steps doesn't screw up the token.
We should look at this bug in 3.1 or 3.2.
Assignee: lord → relyea
Target Milestone: --- → 3.1
Target Milestone: 3.1 → 3.2
QA Contact: lord → sonmi
Target Milestone: 3.2 → 3.3
Target Milestone: 3.3 → Future
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
Bob,

Can you confirm this is resolved and close if appropriate ?
QA Contact: bishakhabanerjee → jason.m.reid
This is still a problem today, on WinXP, even though we now have a PKCS#11
module.  

My test was:
- Have an old signed message from Lord with an old (now expired) cert, 
  cert is already in DB (signed message has previously been read).
- get new signed message from Lord with new unexpired cert, same email address.
- go into cert manager and delete old expired cert.
- cert manager shows that it sees new cert, but attempt to send encrypted
  message says no cert found for his email address.  

Workaround was to delete all certs for Lord, then visit newest email 
which then reimported newest cert for Lord.
Priority: P3 → P2
Target Milestone: Future → ---
QA Contact: jason.m.reid → libraries
I can not reproduce this bug.

In comment 4 Nelson no longer mentioned a cert db corruption.
I believe this problem is fixed.

Nelson talked about a different problem, 
not being able to send encrypted mail, 
because receipient cert is not found.
However, he mentions a workaround is possible.

I believe, the cause for "not found" is bug 335021.

I tried to reproduce Nelson's description in comment 4.
I prepared a cert database, by setting my computer's clock
to a date in the past, so reading an old signed message from
lord imports the cert (as we usually don't import expired certs).
With this prepared cert db as a starting point, I
can reproduce the following steps:

- start
- open cert manager
- I have one cert (only) from lord, expired
- close cert manager
- I open a recent signed message from lord
- I go to cert manager
- now I see two certs from lord
- I delete the old cert
- I see one cert from lord
- close cert manager
- compose a message to lord
- hit security button
- security info tells me, valid cert for lord is available

In addition I tried
- I go to cert manager
- I delete the new cert
- close cert manager
- open cert manager
- lord's cert is still gone
- compose encrypted message to lord
- not possible, cert not found

I conclude, cert DB corruption is not reproducible,
original bug WORKSFORME.

I can't reproduce Nelson's problem in comment 4, 
WORKSFORME.

If Nelson is still able to reproduce the "not found",
I hope, you will no longer be able to reproduce,
once we use the hotfix from bug 335021.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
let's do a final test after bug 335021 gets checked in, adding dependency.
Depends on: 335021
You need to log in before you can comment on or make changes to this bug.