Closed Bug 334293 Opened 18 years ago Closed 18 years ago

nextUpdate used uninitialized in nsCRLInfo::nsCRLInfo if crl->nextUpdate.len == 0

Categories

(Core :: Security: PSM, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: timeless, Assigned: KaiE)

References

(Blocks 1 open bug, )

Details

(Keywords: coverity, fixed1.8.1, Whiteboard: [CID 463])

Attachments

(1 file)

i don't think this is a big deal, but something should be done for it.
Attached patch Patch v1Splinter Review
Attachment #219029 - Flags: review?(rrelyea)
Comment on attachment 219029 [details] [diff] [review]
Patch v1

r+ 

At least this generates defined behavior, though there is a slight problem with the way these are used. The callers do not take nextUpdate and lastUpdate of '0' to be special.

This means is we are fetching crl's based on an interval, then we will always think it's time to fetch the crl (because lastUpdate of zero implies that CRL was last updated sometime in the 1970's).

Perhaps lastUpdate should be set to PR_Now if it doesn't exist.

bob
Attachment #219029 - Flags: review?(rrelyea) → review+
Coverity CID 463
Whiteboard: [CID 463]
fixed on trunk
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment on attachment 219029 [details] [diff] [review]
Patch v1

should this correctness fix go to the 1.8 branch?
Attachment #219029 - Flags: approval1.8.1?
Comment on attachment 219029 [details] [diff] [review]
Patch v1

a=darin on behalf of drivers
Attachment #219029 - Flags: approval1.8.1? → approval1.8.1+
fixed1.8.1
Keywords: fixed1.8.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: