Closed
Bug 49250
Opened 25 years ago
Closed 25 years ago
nsJARChannel::Open computes principal too aggressively
Categories
(Core :: Security: CAPS, defect, P3)
Core
Security: CAPS
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: warrensomebody, Assigned: security-bugs)
References
Details
Attachments
(1 file)
2.98 KB,
patch
|
Details | Diff | Splinter Review |
Subject:
Speeding up jar protocol
Date:
Thu, 27 Jul 2000 23:42:12 -0700
From:
Warren Harris <warren@netscape.com>
To:
Mitchell Stoltz <mstoltz@netscape.com>
Mitch,
I think that the jar protocol is slow because in the Open method we get the
certificate principal from the jar entry (code after the comment //-- Verify
signature, if one is
present, and set owner accordingly). Is there some way we can defer computing
this? If the jar channel is wrapped in a chrome url, we're just going to grab
the system principal
later anyway.
Warren
Reporter | ||
Comment 1•25 years ago
|
||
If we turn on jar packaging without fixing this problem, people will shoot us
for making the startup time so slow. Marking nsbeta3.
Reporter | ||
Comment 2•25 years ago
|
||
Assignee | ||
Comment 4•25 years ago
|
||
There's a problem with this patch. Computing the principal requires mJAR (note
mJAR->GetCertificatePrincipal) but when GetOwner() is called there's no guarantee
that mJAR is still around; it gets released in the Close() function which may or
may not happen before GetOwner() is called. We might have to keep mJAR around
longer. Otherwise this patch will cause some segfaults.
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Reporter | ||
Comment 5•25 years ago
|
||
Can you just reopen the jar again? It will probably be in the cache anyway.
Otherwise, you could hang on to mJAR until the channel is destroyed.
Assignee | ||
Comment 6•25 years ago
|
||
Which do you suggest?
Reporter | ||
Comment 7•25 years ago
|
||
Let's try reopening it if it's needed.
Comment 8•25 years ago
|
||
checking in warren's fix for this. If there are problem, let me know and
reopen.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 9•25 years ago
|
||
We still need to free mJAR from the nsZipReaderCache somewhere; just commenting
out the code in Close() is not enough. As it stands, mJAR will never be freed. I
have a major rewrite of nsJARChannel ready to go in, just waiting on Warren's
review, and it includes this fix, so I will reclose this bug when the full
changes go in.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reporter | ||
Comment 10•25 years ago
|
||
No, we changed the zip cache so that when the channel drops its reference, the
entry gets removed from the cache automatically. In this case, it's when the
channel goes away.
Closing this -- the other bug will deal with your jar channel rewrite.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•