1771192 - build and sign upstream NSIS DLLs in automation

Status: NEW

(Firefox Build System :: Toolchains, enhancement)

Description

[[e-mail] (:bhearsum)]

(I made an edit to this to account for both DLLs that ship with NSIS, as well as plugins that we include separately.)

Our installer relies on a number of DLLs that come from the NSIS binary release, as well as some DLLs that we vendor in-tree. None of these files are signed when we obtain them, and in certain Windows configurations this can cause the installer to fail to run. We're applying a short term workaround for this in bug 1751450 - but we should invest in a more robust fix.

To deal with the unsigned upstream DLLS, I propose that we create a new task downstream of the nsis toolchain task that:

• Downloads the nsis toolchain package
• Signs any DLLs it finds inside of it
• Publishes a new package with the signed versions of the DLLs

We'd then modify all of the jobs that currently depend on the nsis toolchain task (ie: windows builds) to pull the nsis package from the new signing task.

--

The DLLs in-tree end up packed into the setup.exe produced by Windows build tasks. There's already a signing job downstream of this that signs that file, and we could in theory unpack it and sign the innards, but we don't have a Gecko environment to rebuild it as setup.exe -- so it's not a very viable option IMO. Other options include:

• Create new tasks upstream of Windows builds that are responsible for building setup.exe and signing it
• Create new tasks downstream of Windows builds, and upstream of Windows repackage tasks, that know how to unpack setup.exe, sign it, and repack it
• Don't do anything in automation, and just make sure the plugins we land in tree are signed

Comment 1

[[e-mail] (:bhearsum)]

Attachment: WIP: Bug 1771192: framework for building NSIS plugins as part of Firefox

This sortof works. The main todo is that we need to force them to always build as 32-bit (regardless of Firefox arch), because that's the arch of our installer.

Another way to approach this would be to build these entirely separate from Firefox, and configure our Firefox builds to pull plugins from outside as part of its build (although I'm not sure this is as great...).

Comment 2

[[e-mail] (:bhearsum)]

nshukla was trying to push this along as part of https://phabricator.services.mozilla.com/D184143. The topic of forcing 32-bit builds for the NSIS plugins was raised with the build team, and glandium confirmed that it's not possible to do so.

As I understand it - the right path forward here is to build the NSIS plugins as a toolchain which Firefox would then use, instead of rebuilding the DLLs itself. This might actually make it easier to sign as well - we could sign the DLLs out of the toolchain build, and then consumed the signed versions for the Firefox build.

This probably means there's a few things to do here:

• Massaging whatever build system bits are needed (if any) to build the NSIS plugins independently
• Massaging the Gecko build system to be able to find prebuilt NSIS DLLs outside of the source tree (and we should probably remove the checked in ones before all is said an ddone)
• Create a new toolchain build for the NSIS plugins
• Create a new task to sign the NSIS toolchain artifacts
• Wire up Firefox builds to the signed toolchain tasks

Glandium - does that sound reasonable to you?

Comment 3

[Mike Hommey [:glandium]]

As I mentioned on matrix, it's also probably possible to write a nsis script to achieve the same goal (rather than a binary plugin), which, while not necessarily simpler in terms of code, surely is going to be simpler in terms of number of moving pieces.

Comment 4

[[e-mail] (:bhearsum)]

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=1879717 has some work on building 32-bit DLLs in a 64-bit configuration that might be able to help get this unstuck.