Able to corrupt cert7.db



19 years ago
13 years ago


(Reporter: bugzilla, Assigned: rrelyea)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)




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

  Here's the steps to corrupt cert7.db:

  1. I fetched the cert for 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 in cert7.db.
  3. I search for in ldap again. It says it finds one, then  
  I view, I still see far so good.
  4. I delete's cert. It asks if I want to delete #04:F7, I 
  confirm, and it deletes it.
  5. still shows up in the list, but I can't view, delete, or 
  verify this entry.  Database is corrupt.  Bummer.


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.

Comment 1

19 years ago
We should look at this bug in 3.1 or 3.2.
Assignee: lord → relyea
Target Milestone: --- → 3.1


19 years ago
Target Milestone: 3.1 → 3.2


19 years ago
QA Contact: lord → sonmi


18 years ago
Target Milestone: 3.2 → 3.3


18 years ago
Target Milestone: 3.3 → Future


17 years ago
Blocks: 123929

Comment 2

17 years ago
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee

Comment 3

14 years ago

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

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, 

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.
Last Resolved: 13 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.