60352 - RFE: Add CRC check to installer

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P1)

Description

[Henrik Gemal]

It could be cool if there where added CRC check to the mozilla installer file
(mozilla-win32-installer.exe) so that if the file is not complete or is
corrupted a warning is shown to the user.
Winamp has this check. It says:
"CRC check on installer failed. This means that the installer was not
transferred correctly. Please try to redownload the installer."

Comment 1

[Henrik Gemal]

For inspiration you can look at SuperPiMP:
http://www.winamp.com/nsdn/superpimp/

The source is at:
http://www.winamp.com/nsdn/superpimp/superpimp101.jhtml

Comment 2

[Daniel Veditz [:dveditz]]

Some work on this has already been done and checked in. Will leave this as the
placeholder to hook the installer front ends into the backend code.

Need Mac and Linux versions of this bug. 

Comment 3

[Daniel Veditz [:dveditz]]

Moz 0.8 tasks

Comment 4

[Sean Su]

Patch will be attached to bug 66480 to eliminate duplicating patch attachments.

Comment 5

[Sean Su]

fixed.

Comment 6

[Henrik Gemal]

hmmm... how is this done?
I just took a hex editor and changed some bits here and there, saved and 
relaunched, and no CRC error?

Comment 7

[Sean Su]

the CRC check is done the .xpi files themselves *after* they have been
uncompressed.  The CRC checking code is in setup.exe not the self-extracting
.exe file.  To verify this bug, do the following:
1) run mozilla-win32-installer.exe -u
2) corrupt any one (or more than one) of the .xpi files
3) run setup.exe from that directory.

It is using the same CRC checking code that performs CRC checking on downloaded
.xpi files.

To verify the CRC checking for downloaded .xpi files, you can do this for right
now *if* you have an ftp server available to you:
1) run mozilla-win32-installer.exe -u
2) copy *.xpi and MozillaUninstall.exe to your ftp server.  For this example,
lets say the url is ftp://my.ftp.com/mozilla/xpi
3) edit config.ini.  Change the following key:
     [General]
     url=ftp://not.needed.yet.until.release.eng.is.ready

   to
     [General]
     url=ftp://my.ftp.com/mozilla/xpi
   save the config.ini file
4) make sure there are no *.xpi and MozillaUninstall.exe files in the same
folder as the setup.exe.
5) run setup.exe

This will also let you verify the network download functionality in the installer.

Did you want the self-extacting .exe file to perform the CRC checking?  I rather
not do it in the hopes of trying to keep the installer code from getting bigger.
 Maybe is should be another bug?

Comment 8

[Henrik Gemal]

This is not working...:(
Just downloaded the installer. Did -u and changed the "browser.xpi" with a hex 
editor. Mozilla verifies the files just fine. No error.

Comment 9

[Sean Su]

try running the .xpi file thru zip.exe:
  zip -T browser.xpi

We're pretty much doing what zip -T does.

Comment 10

[Sean Su]

marking it back to fixed to get it out of radar.

Comment 11

[Henrik Gemal]

I can see what you mean now. But I'm still able to hex change some bits in the 
file, without getting any CRC errors...

Comment 12

[Sean Su]

it is possible to have changed bits that do not affect the archive.  The crc
checking is done on each file within the archive, not the archive as a whole.

If you run zip -v browser.xpi, you will see the crc numbers next to each of the
files within the archive.

Comment 13

[Daniel Veditz [:dveditz]]

We discussed an alternate design that involved embedding an overall checksum of 
each archive into the downloader stub but decided against it, at least for now.

- XPInstall will also benefit from the zip-archive "testing" code. There would 
be no equivalent way for XPInstall to foresee the CRC for arbitrary .xpi 
archives.
- By using the built-in CRCs we don't have to overly tie the installer stub to 
the archives, so that if the stub is distributed widely and then we update the 
archives on the server we won't have broken anything.

Two drawbacks to the current method: we don't have a checksum for non-zip 
components (such as the JRE executable in the windows installer), and if 
download damage happens to fall in archive directory information rather than in 
the archived data itself then we probably won't detect it until the install 
fails.

We'll try it this way for a while, it'll probably solve the majority of the 
problem. If it's not good enough we can try the more cumbersome mechanism, and 
won't have lost much because XPInstall will still benefit from the work done 
for this bug.

Comment 14

[Henrik Gemal]

I think is current solution is just fine. It will take 95% of all errors...