352555 - updater.exe is not signed.

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Doug Turner (:dougt)]

Under Vista, when applying an update as a standard user, I am presented "User Account Control" dialog box. In this dialog, i can see that updater.exe is not signed by Mozilla.

Comment 1

[Mike Schroepfer]

Ok - we are cutting 1.8.1 in minutes so this will have to defer for a 2.0.0.1 branch.

Comment 2

[Doug Turner (:dougt)]

it looks like 7zip can uncompress nsis sea's.  So, we can do something like:

rm -f nonlocalized/updater.exe
7z x firefox-2.0.en-US.win32.installer.exe  nonlocalized/updater.exe
echo sign updater.exe
7z a firefox-2.0.en-US.win32.installer.exe  nonlocalized/updater.exe

However, this doesn't work.  It appears that 7z can not add back files to the .exe in any nested directory.

Unless there are other tools that can crack a NSIS installer, is it possible to move updater.exe to the top level of the installer sea?

Comment 3

[Benjamin Smedberg]

I would not expect "7z a" to work under any circumstances on the .exe file. You should have to repack the stub+tag+app.

Comment 4

[Doug Turner (:dougt)]

nsis sea's are supported (to some degree as I mentioned above) by 7zip.

the build team was hoping to do all of the signing in one place -- they do not want to sign during the build process but rather after the build and packaging is complete.  So the idea was that we would be able to pull a file out of the .exe, sign it, and then place it back into the .exe.  At that point, sign the entire .exe.

 

Comment 5

[Robert Strong (they/them - no direct email)]

The sea's are 7-Zip sea's and not nsis sea's.

Comment 6

[Doug Turner (:dougt)]

thanks for the clarification.  

In any case, it seams like I can't add a single file.  Another option is just to decompress the whole archive, sign the needed bits, then repackage it.

Comment 7

[Robert Strong (they/them - no direct email)]

Correct, see comment #3... it will need to be repackaged or signed before it is packaged.

Comment 8

[Doug Turner (:dougt)]

Would something like this work:

7z x <installer.exe>  *
rm -rf <installer.exe>
echo sign nonlocalized/updater.exe
7z a <installer.exe>  *
echo sign <installer.exe>

Comment 9

[Doug Turner (:dougt)]

preed needs to run with it.

Comment 10

[J. Paul Reed [:preed]]

sign-release.pl, the sign-release(.sh) replacement is posted at the URL above, along with a log file from a test run.

Comment 11

[Benjamin Smedberg]

I'm worried about this:

I) what needs to happen with the NSS signing step?

Secondly it seems like signing is a timestamp-senstive process. This has a ccouple implications:

1) signing each locale separately means that each locale would have different checksums for binary bits. Since AV vendors and others may be using hashes to determine whether firefox.exe is correct, this could be a problem.

2) we are signing the installer and the MAR separately. This probably means that partial updates will be broken.

I'd like to suggest that, instead of signing each build separately, we use the following technique:

a) Take the installer, find and sign the executables and DLLs and archive them
b) put those same signed executables/DLLs in the complete MAR as well as all the localized installers and MARs

Comment 12

[J. Paul Reed [:preed]]

(In reply to comment #11)
> I'm worried about this:
> 
> I) what needs to happen with the NSS signing step?

I am embarrassingly unfamiliar with what this step does/what it's for. :-/

> Secondly it seems like signing is a timestamp-senstive process. This has a
> ccouple implications:
> 
> 1) signing each locale separately means that each locale would have different
> checksums for binary bits. Since AV vendors and others may be using hashes to
> determine whether firefox.exe is correct, this could be a problem.

In thinking about it, we might solve this by signing the en-US bits which we push to the l10n servers to repack; as long as the l10n repack doesn't change those bits--and I don't think it does--we'd solve this problem.

> 2) we are signing the installer and the MAR separately. This probably means
> that partial updates will be broken.
> 
> I'd like to suggest that, instead of signing each build separately, we use the
> following technique:
> 
> a) Take the installer, find and sign the executables and DLLs and archive them
> b) put those same signed executables/DLLs in the complete MAR as well as all
> the localized installers and MARs

The only issue with that is that it puts the signing process into the tinderbox infrastructure, and requires that we put the private keys on all the Tinderboxen and leave the automation we use to input the key password running all the time.

If we do this, then the utility of signing our binaries goes down somewhat, since anyone with a login could sign a binary, and if someone can get into the build network, then suddenly the keys are all useless.

We've traditionally kept the signing server and process distinctly separate from the build process for this reason.

Having said that, I understand that we may have to come up with a "creative" way to handle this for release builds, because we really do need signing in the middle of the process for this to be not-a-nightmare.

Comment 13

[Mike Connor [:mconnor]]

moving out, need for 2.0.0.2

Comment 14

[Benjamin Smedberg]

> > I) what needs to happen with the NSS signing step?
> 
> I am embarrassingly unfamiliar with what this step does/what it's for. :-/

wtc, can you comment? if we use code signing for the NSS DLLs, does that mean we need to re-run shlibsign?

> The only issue with that is that it puts the signing process into the tinderbox
> infrastructure, and requires that we put the private keys on all the
> Tinderboxen and leave the automation we use to input the key password running
> all the time.

This isn't necessary.

1) Tinderbox makes builds (installer and full MAR)
2) QA certifies
3) We manually sign the en-US installer. We unpack the full MAR and replace firefox.exe with the signed version from the installer. We remake the full MAR.
4) Repack all the locales from the firefox-installer-signed.exe and firefox-fullmar-signed.mar

Comment 15

[Wan-Teh Chang]

I am not familiar with updater.exe and how you build your installer.

NSS consists of six DLLs.  Two of them, freebl3.dll and softokn3.dll,
need to be signed with the shlibsign tool.  shlibsign puts the
signatures in freebl3.chk and softokn3.chk.

If you modify the freebl3.dll and softokn3.dll binaries in any way,
you need run shlibsign on freebl3.dll and softokn3.dll to regenerate
freebl3.chk and softokn3.chk.

If your own signing procedure doesn't touch freebl3.dll and softokn3.dll,
then you don't need to worry about the NSS signing step.

Comment 16

[J. Paul Reed [:preed]]

This is fixed in 2.0.0.1, but we want it in 1.5.0.10.

Changing milestone.

Comment 17

[Jay Patel [:jay]]

Set blocking1.8.0.10+, since we need this on the 1.8.0 branch for the next release.

Comment 18

[J. Paul Reed [:preed]]

These are process changes, so they'll show up to be verified when builds are spun.

Comment 19

[(not reading, please use [e-mail] instead)]

we'll need to sign the uninstaller (soon to be renamed helper.exe, see bug #368353)

preed, do you want a new bug on that, or should I morph this one to include both?

Comment 20

[J. Paul Reed [:preed]]

(In reply to comment #19)
> we'll need to sign the uninstaller (soon to be renamed helper.exe, see bug
> #368353)
> 
> preed, do you want a new bug on that, or should I morph this one to include
> both?

The signing tool signs every .exe/.dll in the installer package with the exception of a couple of NSS .dlls; so neither is necessary; it'll get signed either way.

And in fact, I should just mark this fixed, since it's now a verification issue.

Comment 21

[Carsten Book [:Tomcat]]

verified for 1.8.1.2 with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.2) Gecko/2007020823 Firefox/2.0.0.2 (RC2) updater.exe and helper.exe are signed.

I can`t verify this for 1.8.0.10 at the moment, because this builds are not signed currently.