[RESOLVED] 2.9.0.4 AMO download is corrupt.

[grid2]

There is no META-INF folder

Are those two particular files identical?

Can you post those files someplace for download?

Are you able to capture detailed logs of the downloads, perhaps including the particular CloudFront server they came from?

===================
Yes. Two files are identical, only amo urls differ. Checksums are identical as you mentioned previously on Fri Feb 12, 2016 3:44 am.

However checksums do no match with noscript 2.9.0.4 at https://secure.informaction.com/downloa ... .9.0.4.xpi
MD5 Checksum: DD43B9EE45971B13F076B9DCE96B5E1D
SHA-1 Checksum: 5D348A667941FFAE69D8FD6E36DC01611B5F9766
SHA-256 Checksum: 94D036FF45116023BDE97E6DEE6C79DAF2D28804764BFA8937F5D4D3463173F5

===================

Files posted>, copy/paste 765652 in file ID box.

===================

Downloaded examdiff pro and compared these:
noscript_security_suite-2.9.0.4-fx+fn+sm.xpi (amo download) versus noscript-2.9.0.4.xpi (informaction download)

Diff report (*.jpg) in zip. See posted>.

Checked different compression utilities.
It appears 7-zip does not show the META-INF folder.
Peazip portable also does not show the META-INF folder.
Both Zipware and Izarcgo show META-INF folder but extraction fails.

[grid2]

dig from windows using ICS Bind 9.

Code: Select all

; <<>> DiG 9.10.3-P3 <<>> addons.cdn.mozilla.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37611
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;addons.cdn.mozilla.net.                IN      A

;; ANSWER SECTION:
addons.cdn.mozilla.net. 50      IN      CNAME   d1sp2sgy246t7c.cloudfront.net.
d1sp2sgy246t7c.cloudfront.net. 50 IN    A       54.230.196.197

;; Query time: 2745 msec
;; SERVER: 84.116.46.20#53(84.116.46.20)
;; WHEN: Sun Feb 14 21:14:48 W. Europe Standard Time 2016
;; MSG SIZE  rcvd: 96

[RDL]

and mine..

Code: Select all

.\dig addons.cdn.mozilla.net

; <<>> DiG 9.10.3-P3 <<>> addons.cdn.mozilla.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 975
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;addons.cdn.mozilla.net.                IN      A

;; ANSWER SECTION:
addons.cdn.mozilla.net. 8       IN      CNAME   d1sp2sgy246t7c.cloudfront.net.
d1sp2sgy246t7c.cloudfront.net. 8 IN     A       54.230.196.197

;; Query time: 15 msec
;; SERVER: 194.168.4.100#53(194.168.4.100)
;; WHEN: Sun Feb 14 23:31:09 GMT Standard Time 2016
;; MSG SIZE  rcvd: 107

[barbaz]

Interesting, both have the same IP and it's different from what I get. Now if someone who is affected is able to fake your DNS lookup for addons.cdn.mozilla.net to point only to the IP in my DNS lookup (52.84.3.72) do you get the correct XPI download?

I think that should then be enough information for either Giorgio or someone who is affected, to file an AMO bug (https://bugzilla.mozilla.org/enter_bug. ... ozilla.org, file under Administration component).

(Or is this related? https://github.com/mozilla/addons-server/issues/1111)

[RDL]

Interesting, both have the same IP and it's different from what I get. Now if someone who is affected is able to fake your DNS lookup for addons.cdn.mozilla.net to point only to the IP in my DNS lookup (52.84.3.72) do you get the correct XPI download?

I think that should then be enough information for either Giorgio or someone who is affected, to file an AMO bug (https://bugzilla.mozilla.org/enter_bug. ... ozilla.org, file under Administration component).

(Or is this related? https://github.com/mozilla/addons-server/issues/1111)

Would routing addons.cdn.mozilla.net to 52.84.3.72 in the host file achieve that?

I can't do that tonight but might try tomorrow if it could work and no-one has a simpler way.

I posted a query in that github thread, referencing this one.

[barbaz]

Would routing addons.cdn.mozilla.net to 52.84.3.72 in the host file achieve that?

I would think so, but on some systems it's not that simple...
Test: Route some valid domain to 0.0.0.0 in HOSTS and see if your browser stops being able to connect to that domain.

[Guest]

I was receiving the message 'There was an error downloading NoScript' when trying to update from 2.9.0.3 to 2.9.0.4 from within the Firefox Add-ons Manager page for the past few days. Installed directly from https://noscript.net/getit without any issues. Would this be down to the same issue?

[barbaz]

It probably would be, yes.

[RDL]

Using the hosts file, I redirected addons.cdn.mozilla.net to 52.84.3.72.

Tested with ping addons.cdn.mozilla.net and it showed 52.84.3.72

(but dig still showed 54.230.196.197 as it bypasses the hosts file - see this article:
[SOLVED] nslookup, host, dig not resolving entries in /etc/hosts
http://www.linuxquestions.org/questions ... ts-326300/ )

However, with the redirection in hosts, I then downloaded (right-click>Save Link As) from the AMO link

https://addons.mozilla.org/firefox/down ... xpi?src=ss

This time the correct file was downloaded, with META-INF included.

I have not yet done a file comparison but will after posting. However, I expect the file will match the one from developer's site, as the AMO address used is same as yours, barbaz.

So the DNS sends me to a download address 54.230.196.197 where the unsigned/corrupt file is delivered (accompanied by the CRC for the signed version)

but if I use 52.84.3.72, I get the correct file.

Can that be caused by different regional mirrors? I'm in UK. Where are others who have/do not have this problem?

Can it be caused by problems with/faulty/compromised DNS?

Where now, do you think?

[Guest]

However, on the other hand, I was not getting this problem with other xpi's downloaded from AMO by the same means so what does that tell us?

Simply a mess on a mirror but only for some of its content?

[barbaz]

My guess is that one specific IP/mirror used by addons.cdn.mozilla.net (that is, the IP/mirror it wants to give you, 54.230.196.197) simply never got the signed xpi, but guessing isn't useful here, the only way to find out for sure what's going on is to file a bug. I would suggest that if you don't get a reply at the Github thread tomorrow, to file a bug on Bugzilla the next day.

-----

FWIW, IP information for the "broken" IP:

Code: Select all

General IP Information
IP:	54.230.196.197
Decimal:	921093317
Hostname:	server-54-230-196-197.lhr50.r.cloudfront.net
ASN:	16509
ISP:	Amazon Technologies
Organization:	Amazon.com
Services:	None detected
Type:	Corporate
Assignment:	Static IP
Blacklist:	
Geolocation Information
Continent:	North America
Country:	United States us flag
State/Region:	Washington
City:	Seattle
Latitude:	47.542  (47° 32′ 31.20″ N)
Longitude:	-122.3123  (122° 18′ 44.28″ W)
Postal Code:	98108

And for the "working" IP address I posted earlier:

Code: Select all

General IP Information
IP:	52.84.3.72
Decimal:	877921096
Hostname:	server-52-84-3-72.ord54.r.cloudfront.net
ASN:	16509
ISP:	Amazon Technologies
Organization:	Amazon.com
Services:	None detected
Type:	Corporate
Assignment:	Static IP
Blacklist:	
Geolocation Information
Continent:	North America
Country:	United States us flag
State/Region:	Washington
City:	Seattle
Latitude:	47.6344  (47° 38′ 3.84″ N)
Longitude:	-122.3422  (122° 20′ 31.92″ W)
Postal Code:	98109

(Weird, now my DNS lookup returns a different, also working, IP - 52.84.3.15 )

[grid2]

Amo xpi download now signed. Appears issue has been resolved.
Dig results:

Code: Select all

; <<>> DiG 9.10.3-P3 <<>> addons.cdn.mozilla.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29742
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;addons.cdn.mozilla.net.                IN      A

;; ANSWER SECTION:
addons.cdn.mozilla.net. 50      IN      CNAME   d1sp2sgy246t7c.cloudfront.net.
d1sp2sgy246t7c.cloudfront.net. 50 IN    A       54.192.128.217

;; Query time: 2928 msec
;; SERVER: 84.116.46.20#53(84.116.46.20)
;; WHEN: Tue Feb 16 14:28:20 W. Europe Standard Time 2016
;; MSG SIZE  rcvd: 96

[RDL]

Amo xpi download now signed. Appears issue has been resolved.

Not for me.

I tried several times and got one 'good' download but since then all others still duff.

Incidentally, I tried going through the en-US AMO page and also en-GB but outcome was the same.

I'll leave it another day (in case things are clearing out of buffers) and then submit that bug report. Busy tomorrow so probably on Thursday.

[RDL]

I have submitted the following Bug Report.

1249402 – AMO Server at 54.230.196.197 Delivers Unsigned Download of NoScript 2.9.0.4 xpi File
https://bugzilla.mozilla.org/show_bug.cgi?id=1249402

If you are an interested party, please go to that site (,register) and Vote for it.

NB; If you have additional information which may be helpful in solving the problem, please add it to the bug report but otherwise please stick to just voting since, at Bugzilla, "Me too" is treated as spam and is most likely to delay anyone taking interest.

I have pointed bug readers to this forum topic.

[RDL]

This AMO problem has now been resolved by clearing the AMO CDN cache for that server.

The bug and discussion at Moz Bugzilla and Github have been closed.

(A similar, later Moz bug was also raised for another, different, extension - see:

1251017 – Extension corruption with "save link as" (regional?)
https://bugzilla.mozilla.org/show_bug.cgi?id=1251017

)

Thanks to all.