Closed Bug 1249402 Opened 10 years ago Closed 10 years ago

AMO Server at 54.230.196.197 Delivers Unsigned Download of NoScript 2.9.0.4 xpi File

Categories

(addons.mozilla.org Graveyard :: Administration, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: rdlymail-moz9bugzilla, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:44.0) Gecko/20100101 Firefox/44.0 Build ID: 20160210153822 Steps to reproduce: In Firefox x64 44.0.2 on Win 7 x64 SP1: Check (ping) that, as for me always, addons.cdn.mozilla.net is resolved to 54.230.196.197 Go to AMO (en-US or en-GB) page for NoScript Security Suite 2.9.0.4 Right-click on 'Add to Firefox' button Choose 'Save Link As' Choose a destination folder for the downloaded xpi file. Actual results: The downloaded xpi file does not contain a 'META-INF' file (7-zip shows this) and fails to install when I use 'Install Add-on From File..' in Add-ons Manager. Expected results: The downloaded xpi file should contain a 'META-INF' file and should install correctly using 'Install Add-on From File..' in Add-ons Manager.
Further Info So far, I have this problem only with NoScript - xpi's from other add-ons appear to download normally. 'Copy Download Link' for this download entry in Download Manager gives: https://addons.cdn.mozilla.net/user-media/addons/722/noscript_security_suite-2.9.0.4-fx+fn+sm.xpi?filehash=sha256%3A94d036ff45116023bde97e6dee6c79daf2d28804764bfa8937f5d4d3463173f5 That SHA256 is correct for the proper signed file (as downloaded from the NoScript developer's site) but both 7-Zip and 'Rapid CRC Unicode' give the file actually downloaded from AMO 54.230.196.197 a SHA256 of 7C65095465F8ABC7594DD20AD63E20DE57FD68B015B016B3C03E0D5692EACB4E Fully unpacking those two downloads (AMO and developer site), each into a separate folder, and using WinMerge to compare the folder contents shows the two xpi's to be identical except that the AMO file does not contain a META_INF file whereas that from the developer's site does.. (However, when unpacking the AMO xpi, 7-Zip reported "Q:\TEMP\7-Zip-Temps\AM0 Again\noscript_security_suite-2.9.0.4-fx+fn+sm.xpi Warnings: There are some data after the end of the payload data" ) I also tried installing direct from the link on AMO (left-click on the link). This resulted in the error message: "The add-on could not be installed because it does not match the add-on Firefox expected." During some discussion on the developer's site at InformAction Forums • View topic - 2.9.0.4 AMO download is corrupt. https://forums.informaction.com/viewtopic.php?f=7&t=21609&sid=6e6cb483ae562a061f0852535405e6af it emerged that some other users saw the problem and some did not. One of those without the problem saw that, for them, addons.cdn.mozilla.net resolved to to 52.84.3.72 When I temporarily used my 'hosts' file to force redirection of addons.cdn.mozilla.net to to 52.84.3.72, then, for me also,, as expected, the file which downloaded from that AMO server, using 'Save Link As' on the AMO site, contained the META-INF folder gave the correct SHA256 in both 7-Zip and 'Rapid CRC Unicode' and, when compared in WinMerge, exactly matched the xpi file downloaded from the NoScript developer's site. I first posted this problem on the NoScript user forum on Thu 11 Feb 2016 at 23:38 their time. The problem still persists for me. A more detailed account of this problem and its investigation can be found at the NoScript forum topic linked above - ie: InformAction Forums • View topic - 2.9.0.4 AMO download is corrupt. https://forums.informaction.com/viewtopic.php?f=7&t=21609&sid=6e6cb483ae562a061f0852535405e6af
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Previously I experienced this issue when downloading/installing the add-on. In my case it has been resolved (cloudfront server IP address changed). Can only reproduce bug/incident by adding IP 54.230.196.197 addons.cdn.mozilla.net to hosts file. When downloading "noscript_security_suite-2.9.0.4-fx+fn+sm.xpi" using wget, the server delivers the correct (signed) file. Checksum matches. However, downloading the same file using a browser (firefox, Ironportable, Internet Explorer) the server delivers an unsigned xpi file. The checksum does not match the reported checksum. Checksum (signed) xpi download using wget SHA-256:94D036FF45116023BDE97E6DEE6C79DAF2D28804764BFA8937F5D4D3463173F5 Checksum (unsigned) xpi download using a browser SHA-256:7C65095465F8ABC7594DD20AD63E20DE57FD68B015B016B3C03E0D5692EACB4E
We cleared the CDN cache this Friday to try and fix this issue. Could you try and see if you can reproduce please?
Just tested download from IP 54.230.196.197 using browser(s). META-INF now included in xpi file, checksum match.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
I was not free to check before Sunday 28 Feb but did my regular check then and the download (from my default at 54.230.196.197) then contained META INF OK. I repeated on 29 Feb and (today) 01 Mar to be sure it was holding and fresh downloads were also OK. Since you have now resolved as fixed I won't wait for all seven clear days I intended to check. Confirmed my default download from there on Sun 28 Feb, Mon 29 Feb and (today) Tue 01 Mar all good. Thank you.
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.