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

Status: VERIFIED FIXED

(Core Graveyard :: Installer: XPInstall Engine, defect)

Description

[Jon Stritar]

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

[djpohly]

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?

Comment 2

[Jon Stritar]

Yep it works once that is set to true...

Comment 3

[Nickolay_Ponomarev]

Adding dependency.

Comment 4

[Benjamin Smedberg]

Jon, does this still show up in Firefox 1.5?

Comment 5

[Mike Shaver (:shaver emeritus)]

This still occurs in Firefox 2 and on the trunk.  Raising severity and updating version.

Comment 6

[Benjamin Smedberg]

Is this still a problem? I believe bug 381812 fixed this.

Comment 7

[Wayne Mery (:wsmwk)]

reporter appears to be gone. no response to email either.

Comment 8

[Dave Townsend [:mossop]]

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.

Comment 9

[Robert Sayre]

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.

Comment 10

[Benjamin Smedberg]

Yeah, this is basically a branch duplicate of bug 381812.

Comment 11

[Shawn Wilsher :sdwilsh]

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/[e-mail]/1.1.0.20080106/

Comment 12

[Shawn Wilsher :sdwilsh]

Attachment: netwerk log

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

Hmm. NS_ERROR_ILLEGAL_VALUE.

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

nsAStreamCopier::DoCopy returned that error as the source condition. still investigating.

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

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/[e-mail]/1.1.0.20080106/

Comment 16

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 17

[Daniel Veditz [:dveditz]]

Mossop: is this one you can look into for the branch, or are you swamped with FF3 stuff.

Comment 18

[Dave Townsend [:mossop]]

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.

Comment 19

[Daniel Veditz [:dveditz]]

Not a branch blocker (we've lived with it, unfortunately), but nice to have if possible.

Comment 20

[Dave Townsend [:mossop]]

The way things are right now I'm just not going to have time to get to this in the near future

Comment 21

[Reed Loden [:reed]]

Attachment: patch - v1

Same as attachment 275513 [details] [diff] [review] but without the assert removal, as it doesn't exist on branch.

Comment 22

[Daniel Veditz [:dveditz]]

Comment on attachment 305509 [details] [diff] [review]
patch - v1

approved for 1.8.1.13, a=dveditz for release-drivers

Comment 23

[Reed Loden [:reed]]

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

Comment 26

[John J. Barton]

Is there a workaround for this?  We can't even install Firebug now.

Comment 27

[Reed Loden [:reed]]

(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 ?

Comment 28

[Al Billings [:abillings - ex-MoCo]]

(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/[e-mail]/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/[e-mail]/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

[John J. Barton]

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.

Comment 30

[Al Billings [:abillings - ex-MoCo]]

Attachment: 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).

Comment 31

[Al Billings [:abillings - ex-MoCo]]

In other words, this isn't fixed.

Comment 32

[Shawn Wilsher :sdwilsh]

Thanks for checking this - I haven't had the time.  biesi - any idea what's up still?

Comment 33

[Al Billings [:abillings - ex-MoCo]]

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.

Comment 34

[Reed Loden [:reed]]

$ curl -I https://services.forerunnerdesigns.com/extensions/get/[e-mail]/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!

Comment 35

[Christian :Biesinger (don't email me, ping me on IRC)]

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])

Comment 36

[Christian :Biesinger (don't email me, ping me on IRC)]

the cert problem could be because NSS knows a CA that curl/openssl don't know

Comment 37

[(not currently active) Ted Mielczarek]

Yeah, we had that problem with libcurl and the crash reporter, bug 407748.

Comment 38

[Daniel Veditz [:dveditz]]

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

[John J. Barton]

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.

Comment 40

[Shawn Wilsher :sdwilsh]

(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.

Comment 41

[Reed Loden [:reed]]

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.

Comment 42

[Myk Melez [:myk] [@mykmelez]]

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

Comment 43

[Samuel Sidler (old account; do not CC)]

Dave, can you take a look at this? We'd like to get this fixed in the next Firefox 2.0.0.x release.

Comment 44

[Dave Townsend [:mossop]]

Attachment: 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.

Comment 45

[Dave Townsend [:mossop]]

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.

Comment 46

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 47

[Daniel Veditz [:dveditz]]

Comment on attachment 317239 [details] [diff] [review]
patch v2

Approved for 1.8.1.15, a=dveditz for release-drivers

Comment 48

[Dave Townsend [:mossop]]

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

Comment 49

[Hasham]

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.

Comment 50

[Hasham]

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.

Comment 51

[Steve Zimmelman]

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

Comment 52

[Shawn Wilsher :sdwilsh]

(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.