Closed
Bug 198371
Opened 22 years ago
Closed 19 years ago
wrong looking prefs (security.crl.autoupdate.freqCnt.)
Categories
(Core Graveyard :: Security: UI, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 282945
People
(Reporter: bugzilla, Unassigned)
References
()
Details
when enabling autoupdate for my CA's I'm seeing som weird looking prefs in the
prefs.js file.
like:
user_pref("security.crl.autoupdate.dayCnt.", "1");
user_pref("security.crl.autoupdate.enable.", true);
user_pref("security.crl.autoupdate.freqCnt.", "1");
user_pref("security.crl.autoupdate.nextInstant.", "20-03-2003 00:25:38");
user_pref("security.crl.autoupdate.timingType.", 1);
user_pref("security.crl.autoupdate.url.", "");
these seems wrong!
the complete section looks like:
user_pref("security.crl.autoupdate.enable.", true);
user_pref("security.crl.autoupdate.enable.Certificate Hotel II", true);
user_pref("security.crl.autoupdate.enable.Demo Certification Authority I", true);
user_pref("security.crl.autoupdate.enable.TDC Internet Class II CA", true);
user_pref("security.crl.autoupdate.enable.TDC Internet Systemtest CA I", true);
user_pref("security.crl.autoupdate.enable.Tele Danmark Qualified CA", true);
20030319
Comment 1•22 years ago
|
||
CC'ing Rangan FYI.
Looks like the URL is not saved correctly?
Henrik, which CRL URL do you access to reproduce this problem?
Are you able to reproduce?
Reporter | ||
Comment 2•22 years ago
|
||
reproduce is easy:
start with fresh profile:
then go to:
http://crl.oces.certifikat.dk/oces.crl
and press Yes
then check the "Enable Automatic update" checkbox and click OK
the look af the prefs...
user_pref("security.crl.autoupdate.dayCnt.", "1");
user_pref("security.crl.autoupdate.enable.", true);
user_pref("security.crl.autoupdate.errCount.", 0);
user_pref("security.crl.autoupdate.freqCnt.", "1");
user_pref("security.crl.autoupdate.nextInstant.", "01-04-2003 23:51:05");
user_pref("security.crl.autoupdate.timingType.", 1);
user_pref("security.crl.autoupdate.url.", "");
Reporter | ||
Updated•22 years ago
|
Comment 3•22 years ago
|
||
Henrik, thanks for the example.
You are not stating explicitly what you think looks wrong.
I suspect you are refering to the empty ".url." preference?
While I agree this looks wrong or at least like an unnecessary entry, the
feature still seems to work for me.
I can import the URL, quit, restart, manage CRLs and update. The crl seems to
get loaded again (although I did not check with network monitoring tools).
It appears, the URL is recorded inside the certificate database files (cert8.db).
If the only complaint is to remove the unnecessary URL I suggest to future this.
Rangan, do you remember what is supposed to be recorded in the URL pref?
Reporter | ||
Comment 4•22 years ago
|
||
yes it's just the prefs that are looking wrong.
I just though if there are wrong prefs there's also wrong code. Soo some
problems/bugs could be due to these wrong prefs...:)
but if you only have these prefs:
user_pref("security.crl.autoupdate.dayCnt.", "1");
user_pref("security.crl.autoupdate.enable.", true);
user_pref("security.crl.autoupdate.errCount.", 0);
user_pref("security.crl.autoupdate.freqCnt.", "1");
user_pref("security.crl.autoupdate.nextInstant.", "01-04-2003 23:51:05");
user_pref("security.crl.autoupdate.timingType.", 1);
user_pref("security.crl.autoupdate.url.", "");
how does this relate to the cert8.db? How does it know which CRL to update???
Comment 5•22 years ago
|
||
Good point, I don't know.
Rangan, could you explain how the cert auto update works?
Especially, how do you find the prefs for a CRL in the cert db, and vice versa?
Comment 6•22 years ago
|
||
Kai: Sorry, I should have responded to this one earlier. No, we don't find the
prefs for CRL in the cert db - we read from those prefs in the prefs.js. This
happens in nsNSSComponent::getParamsForNextCrlToDownload. The url param stores
the url where the crl was originally obtained from, and uses it for manual/auto
update. Its weired that this was showing blank - seems to show the right thing
for me with Netscape 7:
user_pref
("security.crl.autoupdate.url.", "http://crl.oces.certifikat.dk/oces.crl");
user_pref("security.crl.autoupdate.url.AT&T WorldNet(R) Certificate Services -
Class 2 Individual CA", "http://crl.verisign.com/ATTClass2Individual.crl");
user_pref("security.crl.autoupdate.url.Class 1 Public Primary Certification
Authority", "http://crl.verisign.com/Class1GW.crl");
Wondering if there has been a regression somewhere..
Comment 7•22 years ago
|
||
My experience is that security.crl.autoupdate.url has a value when autoupdate is
1st enabled. Most of the time, not always, it changes to blank after 1st
autoupdate. If it changes to blank, 2nd autoupdate never happens.
Have tried many CRLs, both V1 and V2, with moz 1.4 and MacOSX, Redhat 8 & 9. I
can't find a pattern. A CRL will have the problem. I delete and reimport and
sometimes it doesn't reoccur. Most of the time it does.
Comment 8•21 years ago
|
||
security.crl.autoupdate.url still blank after 1st autoupdate in 1.5b. Back in
1.4 I had a couple crls complete the 2nd autoupdate. That hasn't happened since.
Comment 10•19 years ago
|
||
*** This bug has been marked as a duplicate of 282945 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•