The default bug view has changed. See this FAQ.

can't install extensions over ssl, fails with message "Download error"

VERIFIED FIXED in mozilla1.8.1

Status

Core Graveyard
Installer: XPInstall Engine
--
critical
VERIFIED FIXED
12 years ago
a year ago

People

(Reporter: Jon Stritar, Assigned: mossop)

Tracking

({verified1.8.1.15})

1.8 Branch
mozilla1.8.1
verified1.8.1.15
Dependency tree / graph
Bug Flags:
blocking1.8.1.12 -
blocking1.8.1.15 +
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1

You can't install extensions over ssl. When the extension manager tries to start
the download, it says "Download error". After that, you can't access anything on
the host that you were trying to download from. So, for example, you can't
access anything at jstritar.mit.edu after trying to do it.

Reproducible: Always

Steps to Reproduce:
1. Click on an xpi at https://jstritar.mit.edu/extensions/forecastfox/
2. Click install


Actual Results:  
"Download Error"

Try to go to another page on the same site:
https://jstritar.mit.edu/mediawiki/index.php/Main_Page or
https://jstritar.mit.edu/ -> it won't work unless you restart the browser.

Expected Results:  
It should install the extension and cause no problems.

Comment 1

12 years ago
Probably belongs in Core / Installer: XPInstall Engine.

SSL is not cached by default, so I'm thinking dupe of bug 262854.  If you
navigate to about:config and set browser.cache.disk_cache_ssl to true, does this
still happen?
(Reporter)

Comment 2

12 years ago
Yep it works once that is set to true...

Comment 3

12 years ago
Adding dependency.
Status: UNCONFIRMED → NEW
Depends on: 262854
Ever confirmed: true
Jon, does this still show up in Firefox 1.5?
Assignee: bugs → xpi-engine
Component: Extension/Theme Manager → Installer: XPInstall Engine
Product: Firefox → Core
QA Contact: bugs
Version: unspecified → 1.7 Branch
This still occurs in Firefox 2 and on the trunk.  Raising severity and updating version.
Severity: normal → major
Flags: wanted1.8.1.x?
Flags: blocking1.9?
OS: Windows XP → All
Hardware: PC → All
Version: 1.7 Branch → 1.8 Branch
Depends on: 381812
Summary: can't install extensions over ssl → can't install extensions over ssl, fails with message "Download error"
Is this still a problem? I believe bug 381812 fixed this.
Flags: blocking1.9? → blocking1.9+
reporter appears to be gone. no response to email either.
(Assignee)

Comment 8

10 years ago
bug 381812 is fixed on trunk however the patch isn't applicable to the branch and I'm told that if this is an issue on branch it would be a different problem. We could dupe this across, or keep it open with the chance to try to work something out for branch.
Assignee: xpi-engine → nobody
QA Contact: xpi-engine

Comment 9

10 years ago
this isn't blocking 1.9 if it's fixed on the trunk. marking "?" for now, please explain if it should block 1.9 and we'll revisit.
Flags: blocking1.9+ → blocking1.9?
Yeah, this is basically a branch duplicate of bug 381812.
Flags: blocking1.9?
OK, so this *is* an issue on branch.  I recently started serving my addons up via ssl so I have them secured like they need to be for Firefox 3.  However, nobody on 2 can download my addons anymore.  This seems to be 100% reproducible with this url (shouldn't go anywhere for a long time)
https://services.forerunnerdesigns.com/extensions/get/rtse-nightly@shawnwilsher.com/1.1.0.20080106/
Severity: major → critical
Flags: blocking1.8.1.12?
Created attachment 295793 [details]
netwerk log
Hmm. NS_ERROR_ILLEGAL_VALUE.
nsAStreamCopier::DoCopy returned that error as the source condition. still investigating.
501         rv = nsCacheService::OpenInputStreamForEntry(cacheEntry, mode,
502                                                      mStartOffset,
503                                                      getter_AddRefs(mInput));

that one returned that error code (nsCacheEntryDescriptor::nsInputStreamWrapper::LazyInit)

(gdb) p/x cacheEntry->mFlags
$4 = 0x7a01

mDataSize is 0, hmm. The key is HTTP-memory-only:https://services.forerunnerdesigns.com/extensions/get/rtse-nightly@shawnwilsher.com/1.1.0.20080106/
So the issue is that nsStorageStream on branch doesn't support reading from empty streams. Basically the same as bug 381812 but needs a different fix.
Mossop: is this one you can look into for the branch, or are you swamped with FF3 stuff.
Flags: wanted1.8.1.x? → wanted1.8.1.x+
(Assignee)

Comment 18

9 years ago
I am pretty tight for time, but biesi has given me an idea of what is going on I might be able to find a spare moment to look at it next week.
Not a branch blocker (we've lived with it, unfortunately), but nice to have if possible.
Assignee: nobody → dtownsend
Flags: blocking1.8.1.12? → blocking1.8.1.12-
(Assignee)

Comment 20

9 years ago
The way things are right now I'm just not going to have time to get to this in the near future
Assignee: dtownsend → nobody
Created attachment 305509 [details] [diff] [review]
patch - v1

Same as attachment 275513 [details] [diff] [review] but without the assert removal, as it doesn't exist on branch.
Attachment #305509 - Flags: review?(benjamin)
Attachment #305509 - Flags: review?(benjamin) → review+
Attachment #305509 - Flags: approval1.8.1.13?
Comment on attachment 305509 [details] [diff] [review]
patch - v1

approved for 1.8.1.13, a=dveditz for release-drivers
Attachment #305509 - Flags: approval1.8.1.13? → approval1.8.1.13+
Assignee: nobody → reed
Status: NEW → ASSIGNED
Keywords: checkin-needed
Checking in xpcom/io/nsStorageStream.cpp;
/cvsroot/mozilla/xpcom/io/nsStorageStream.cpp,v  <--  nsStorageStream.cpp
new revision: 1.31.8.1; previous revision: 1.31
done
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Keywords: checkin-needed → fixed1.8.1.13
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8.1
(Assignee)

Updated

9 years ago
Duplicate of this bug: 417140
Duplicate of this bug: 420349

Comment 26

9 years ago
Is there a workaround for this?  We can't even install Firebug now.
(In reply to comment #26)
> Is there a workaround for this?  We can't even install Firebug now.

Did you read bug 420349, comment #3 ?
(In reply to comment #11)
> OK, so this *is* an issue on branch.  I recently started serving my addons up
> via ssl so I have them secured like they need to be for Firefox 3.  However,
> nobody on 2 can download my addons anymore.  This seems to be 100% reproducible
> with this url (shouldn't go anywhere for a long time)
> https://services.forerunnerdesigns.com/extensions/get/rtse-nightly@shawnwilsher.com/1.1.0.20080106/
> 

Using this url in both 2.0.0.12 and the nightly from 2.0.0.13 right before we snapped for the RC (Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13pre) Gecko/2008030703 BonEcho/2.0.0.13pr), I get the same error in each. It prompts to install the add-on and then gets an error stating:

Bon Echo could not install the file at

https://services.forerunnerdesigns.com/extensions/get/rtse-nightly@shawnwilsher.com/1.1.0.20080106/

because: Download error
-228

Unless that download is messed up in some way, this isn't fixed. 

Note: Trunk installs from that URL without issue.

Comment 29

9 years ago
The bug here is the error message. The download tool should just tell us what the http request result was, not make up a number and say "Download error"

$ wget https://services.forerunnerdesigns.com/extensions/get/rtse-nightly@shawn
wilsher.com/1.1.0.20080106/
--15:14:14--  https://services.forerunnerdesigns.com/extensions/get/rtse-nightly
@shawnwilsher.com/1.1.0.20080106/
           => `index.html'
Resolving services.forerunnerdesigns.com... 67.205.0.226
Connecting to services.forerunnerdesigns.com|67.205.0.226|:443... connected.
ERROR: Certificate verification error for services.forerunnerdesigns.com: unable
 to get local issuer certificate
To connect to services.forerunnerdesigns.com insecurely, use `--no-check-certifi
cate'.
Unable to establish SSL connection.
Created attachment 308727 [details]
Side by Side 20012 and 20013 showing bug

I'm seeing the exact same error message with the released 2.0.0.12 and the branch nightly from 3/7 (Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13pre) Gecko/2008030703 BonEcho/2.0.0.13pre).
In other words, this isn't fixed.
Thanks for checking this - I haven't had the time.  biesi - any idea what's up still?
Status: RESOLVED → REOPENED
Keywords: fixed1.8.1.13
Resolution: FIXED → ---
Reed points out that the sample site has an invalid cert:

curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed

I tried https://www.kormoran.net/smetnywij/kurnikplus/kurnikplus_1030.xpi from
bug 381812 but it has the same bad cert error.
$ curl -I https://services.forerunnerdesigns.com/extensions/get/rtse-nightly@shawnwilsher.com/1.1.0.20080106/
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

$ curl -I https://www.kormoran.net/smetnywij/kurnikplus/kurnikplus_1030.xpi
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Are we even sure this is a Necko problem? Maybe trunk is doing the wrong thing by accepting these bad certificates!
you may need parts of bug 367467 too.

that's why you test patches before attaching them to bugzilla...

Also, you might want to add the unit test from trunk, or at least the part of it that applies to this bug (attachment 277150 [details] [diff] [review])
the cert problem could be because NSS knows a CA that curl/openssl don't know
Yeah, we had that problem with libcurl and the crash reporter, bug 407748.
both forerunnerdesigns.com and kormoran.net are using valid certs from StartCom, a relatively recent addition to our CA list that's not widely supported (doesn't work in IE, for instance).

The cert is not the cause of the error.

Comment 39

9 years ago
The bug is still the error message.  If the HTTP response was shown instead of -228 we would not be having this dicussion, certs or not.
(In reply to comment #39)
> The bug is still the error message.  If the HTTP response was shown instead of
> -228 we would not be having this dicussion, certs or not.
The odds of that getting fixed on branch are extremely low, and it's *not* this bug.  Right now extension install if failing when it should not be.
biesi recommended checking to see if part of the patch from bug 367467 is needed. I don't have the time to work on this, so reassigning to defaults.
Assignee: reed → nobody
Status: REOPENED → NEW
Flags: blocking1.8.1.14?
In case it helps isolate potential CA issues from the bug, I'm seeing this problem on personas XPIs hosted on people.mozilla.com, whose cert is signed by XRamp, f.e.:

https://people.mozilla.com/~cbeard/personas/dist/personas-v0.9.9.xpi

Everything works fine with the non-SSL URL to the same file:

http://people.mozilla.com/~cbeard/personas/dist/personas-v0.9.9.xpi
Dave, can you take a look at this? We'd like to get this fixed in the next Firefox 2.0.0.x release.
Assignee: nobody → dtownsend
Flags: blocking1.8.1.15? → blocking1.8.1.15+
(Assignee)

Comment 44

9 years ago
Created attachment 317239 [details] [diff] [review]
patch v2

I'm still not able to reproduce this issue reliably but I believe that this will work. I have basically used the unit test from trunk and ported the changes from bug 367467 in order to make it pass. Without this patch the test fails 3/4 of the tests, with it it passes them all.
Attachment #317239 - Flags: review?
(Assignee)

Updated

9 years ago
Attachment #317239 - Flags: review? → review?(cbiesinger)
(Assignee)

Updated

9 years ago
Status: NEW → ASSIGNED
Whiteboard: [has patch]

Updated

9 years ago
Blocks: 435025
(Assignee)

Comment 45

9 years ago
This bug and its fix has nothing to do with improving error messages so I do not believe it blocks bug 435025, especially given that this is a branch only bug.
No longer blocks: 435025
Comment on attachment 317239 [details] [diff] [review]
patch v2

I'm not sure that the Write() change is needed to fix this bug but it can't harm.
Attachment #317239 - Flags: review?(cbiesinger) → review+
(Assignee)

Updated

9 years ago
Attachment #317239 - Flags: approval1.8.1.15?
Comment on attachment 317239 [details] [diff] [review]
patch v2

Approved for 1.8.1.15, a=dveditz for release-drivers
Attachment #317239 - Flags: approval1.8.1.15? → approval1.8.1.15+
(Assignee)

Comment 48

9 years ago
Checking in io/nsStorageStream.cpp;
/cvsroot/mozilla/xpcom/io/nsStorageStream.cpp,v  <--  nsStorageStream.cpp
new revision: 1.31.8.2; previous revision: 1.31.8.1
done
Checking in tests/Makefile.in;
/cvsroot/mozilla/xpcom/tests/Makefile.in,v  <--  Makefile.in
new revision: 1.91.2.3; previous revision: 1.91.2.2
done
Checking in tests/unit/test_storagestream.js;
/cvsroot/mozilla/xpcom/tests/unit/test_storagestream.js,v  <--  test_storagestream.js
new revision: 1.3.18.1; previous revision: 1.3
done
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago9 years ago
Keywords: fixed1.8.1.15
Resolution: --- → FIXED
Whiteboard: [has patch]

Comment 49

9 years ago
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.15pre) Gecko/20080610 BonEcho/2.0.0.15pre RTSE/1.1.0.20080106

Verified fixed on 1.8.1.15. I tried this on the test site given on comment 11. Tried this in 1.8.1.14 and it gave the previously mentioned error message, but installs the add-on fine in 1.8.1.15.
Keywords: fixed1.8.1.15 → verified1.8.1.15

Comment 50

9 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.15pre) Gecko/20080610 BonEcho/2.0.0.15pre RTSE/1.1.0.20080106

Also checks out on Windows. Marking as verified.
Status: RESOLVED → VERIFIED

Comment 51

9 years ago
I just got a -228 error trying to install a plug-in from abc.com.

Firefox could not install the file at 
http://player.movenetworks.com/pub/BBB87026/qmp07103010.xpi
because: Download error
-228

1) go to http://abc.go.com/player/?channel=5781
2) click on "watch now"
3) go through the install process.  It won't download.

I get the same error on http://streaming.myfoxboston.com
(In reply to comment #51)
> I just got a -228 error trying to install a plug-in from abc.com.
> http://player.movenetworks.com/pub/BBB87026/qmp07103010.xpi
> I get the same error on http://streaming.myfoxboston.com
Not this bug - it'd be an https url if it was this bug.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.