Closed
Bug 209560
(jar:https)
Opened 22 years ago
Closed 22 years ago
Secure JS doesn't work from https JARs
Categories
(Core :: Networking, defect, P1)
Core
Networking
Tracking
()
RESOLVED
FIXED
mozilla1.5alpha
People
(Reporter: mkaply, Assigned: darin.moz)
References
Details
(Keywords: fixed1.4.1)
Attachments
(2 files, 2 obsolete files)
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
dougt
:
review+
alecf
:
superreview+
mkaply
:
approval1.4.1+
|
Details | Diff | Splinter Review |
Unfortunately I don't have an external site for this, but here is the basics: jar:http://minardi.yamato.ibm.com/GeckoSignedScripts.jar!/GeckoSignedScripts.html works jar:https://minardi.yamato.ibm.com/GeckoSignedScripts.jar!/GeckoSignedScripts.html doesn't. This is a HUGE issue for an IBM product.
Comment 1•22 years ago
|
||
Mike, can you describe the results you see? Does the page load at all? Does it load but the signed script doesn't work?
Status: NEW → ASSIGNED
Comment 2•22 years ago
|
||
the contents of the html file is shown as an empty html file. My secure server however is down too now, trying to see if I can get it up. My signed jar example (none secure site, nscp internal): jar:http://elwood.mcom.com/doron2/icbc/icbcsignedjs.jar!/icbcsignedjs.html
Reporter | ||
Comment 3•22 years ago
|
||
The error necko is simply a "NS_ERROR_NOT_AVAILABLE" I'm going to do some logging.
Assignee | ||
Comment 5•22 years ago
|
||
actually, the problem is that HTTPS content is not written to the disk cache, and jar:http: only works when the content is written to the disk cache. the problem is that we need to first download the jar file to disk, and then we go and load the jar file as if it were a normal file:// URL. fixing this problem will be very tricky. ideally we'd need support for loading jar files from a data stream. or we'd have to bite-the-bullet and write HTTPS content out to disk (which we generally avoid for privacy reasons). this problem is very much related to bug 172279.
Depends on: 172279
Reporter | ||
Comment 7•22 years ago
|
||
So signed Javascript and secure http are mutually exclusive? That seems really bad...
Assignee | ||
Comment 8•22 years ago
|
||
it is... seems to me that the feature was just hacked together. jar:http(s):// really needs to be redesigned from the ground up because anyways the disk cache might not be present in an embedding build. if you're in a pinch and need a quick solution, you might want to go the route of allowing HTTPS content to be written out to the disk cache. IE allows HTTPS content in its disk cache, so its not exactly a crazy idea.
Assignee | ||
Comment 9•22 years ago
|
||
bug 205921 unfortunately needs to be fixed before caching of HTTPS content to disk can be enabled.
Depends on: 205921
Assignee | ||
Comment 10•22 years ago
|
||
here's a possible patch for this bug. what this does is make it so that we will fall back on writing the data stream to a temporary file when the channel cannot provide us with a disk cache file. the temporary file is deleted once the JAR channel finishes loading the contents of the JAR file. obviously, this will have poor performance if multiple items need to be extracted from the JAR file since the entire JAR file will be written out to disk once for each item that is loaded. improving that will require a bit more work, but i suspect this won't be that big of an issue in practice (knock-on-wood). the patch seems to have some issues. namely, the temporary files aren't getting deleted. but for the most part this patch seems to do the trick.
Reporter | ||
Comment 11•22 years ago
|
||
Darin, I know this will never fly with ADT or drivers, but is there any possibility of a safe fix that I could argue into 1.4? This particular bug is going to cause some major IBM applications to not be supported on Netscape or Mozilla. Unfortunately, they didn't inform me of the problems until very recently.
Assignee | ||
Comment 12•22 years ago
|
||
mike: yeah, maybe. i have something simpler in mind that might be good for the 1.4 branch. in fact, i could probably just massage nsHttpChannel::SetCacheAsFile(PR_TRUE) to not fail if SSL. hmm....
Comment 13•22 years ago
|
||
Darin, thanks for working on this. The current cache-stream-as-file mechanism made sense at the time it was written, but that was before embedding. Alternatively, we could get signed scripts working with the old syntax (bug 37333), though that's not feasible for 1.4. That way we wouldn't have to use the jar: protocol for signed scripts.
Assignee | ||
Comment 14•22 years ago
|
||
mitch, no problem. sorry for pointing fingers at stream-as-file... i think too many things changed between its original inception and now, and along the way this was simply broken :-/ i think the solution that i'm going for with this patch is probably the best and safest solution. though the patch is large, the changes are purely confined to the domain of jar:http(s), so the risk is minimal to the overall product. so, it might have a chance of making it onto the 1.4 branch. i just need to shake out a remaining issue... actually, i think i may have uncovered a file descriptor leak in libjar.
Assignee | ||
Comment 15•22 years ago
|
||
ok, same patch cleaned up and working completely. as i mentioned, there was a file descriptor leak in the jar cache (or at least it seems that way to me). in current builds this also means that we would leak disk cache files if the cache tried to delete a file on disk after libjar had read from it. over time, i think the cache would just grow in size as a result of this. of course few people load jar:http, so probably not a big deal in that case.
Attachment #126009 -
Attachment is obsolete: true
Assignee | ||
Comment 17•22 years ago
|
||
.
Alias: jar:https
Assignee: mstoltz → darin
Status: ASSIGNED → NEW
Component: Security: General → Networking
Assignee | ||
Updated•22 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.5alpha
Assignee | ||
Updated•22 years ago
|
Attachment #126100 -
Flags: superreview?(alecf)
Attachment #126100 -
Flags: review?(dougt)
Assignee | ||
Comment 18•22 years ago
|
||
minor changes to the API. now, if an explicit download location is specified, the resulting file will not be deleted when the downloader is destroyed. this allows the consumer to take ownership of the downloaded file.
Attachment #126100 -
Attachment is obsolete: true
Assignee | ||
Updated•22 years ago
|
Attachment #126140 -
Flags: superreview?(alecf)
Attachment #126140 -
Flags: review?(dougt)
Assignee | ||
Updated•22 years ago
|
Attachment #126100 -
Flags: superreview?(alecf)
Attachment #126100 -
Flags: review?(dougt)
Attachment #126100 -
Flags: review-
Comment 19•22 years ago
|
||
Comment on attachment 126140 [details] [diff] [review] v1.1 patch (revised per comments from dougt) r=dougt. this interface is great. you should think about marking it UNDER_REVIEW. I would love to have something like this exposed.
Attachment #126140 -
Flags: review?(dougt) → review+
Assignee | ||
Comment 21•22 years ago
|
||
mkaply: not too risky in my book since this code is only exercised when loading remote jar files.
Comment 22•22 years ago
|
||
Comment on attachment 126140 [details] [diff] [review] v1.1 patch (revised per comments from dougt) sr=alecf
Attachment #126140 -
Flags: superreview?(alecf) → superreview+
Assignee | ||
Comment 23•22 years ago
|
||
Comment on attachment 126140 [details] [diff] [review] v1.1 patch (revised per comments from dougt) seeking drivers approval for 1.4... this looks scarier than it is. the risk is low because the code is only executed when loading remote jar files, but without this jar:https:// won't work at all.
Attachment #126140 -
Flags: approval1.4?
Assignee | ||
Comment 24•22 years ago
|
||
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 25•22 years ago
|
||
Comment on attachment 126140 [details] [diff] [review] v1.1 patch (revised per comments from dougt) moving approval request forward.
Attachment #126140 -
Flags: approval1.4? → approval1.4.x?
Reporter | ||
Comment 26•22 years ago
|
||
Comment on attachment 126140 [details] [diff] [review] v1.1 patch (revised per comments from dougt) I haven't seen any mentions of refressions on this one and we want it for IBM. a=mkaply
Attachment #126140 -
Flags: approval1.4.x? → approval1.4.x+
Assignee | ||
Comment 29•22 years ago
|
||
ok, minor tweak to the keyword... fixed1.4.1 instead of fixed1.4 (thanks kaie!)
Keywords: fixed1.4 → fixed1.4.1
You need to log in
before you can comment on or make changes to this bug.
Description
•