198371 - wrong looking prefs (security.crl.autoupdate.freqCnt.)

Status: RESOLVED DUPLICATE of bug 282945

(Core Graveyard :: Security: UI, defect)

Description

[Henrik Gemal]

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

[Kai Engert (:KaiE:)]

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?

Comment 2

[Henrik Gemal]

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.", "");

Comment 3

[Kai Engert (:KaiE:)]

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?

Comment 4

[Henrik Gemal]

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

[Kai Engert (:KaiE:)]

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

[Rangan Sen]

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

[Larry Riffle]

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

[Larry Riffle]

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 9

[John G. Myers]

Mass reassign ssaux bugs to nobody

Comment 10

[Kai Engert (:KaiE:)]

*** This bug has been marked as a duplicate of 282945 ***