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.

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

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?

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

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.

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

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.

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

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>

preed needs to run with it.

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

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

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

moving out, need for 2.0.0.2

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

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.

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

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

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

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?

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

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.