1361402 - Support windows internals signing on signingserver/signingworkers

Status: RESOLVED DUPLICATE of bug 1368192

(Release Engineering :: General, enhancement)

Description

[Justin Wood (:Callek)]

For TC Migration of windows, we'll need to support signing "internal" binaries as a seperate step from signing the "external" files.

Specifically internal files are stuff like:
  firefox.exe, xul.dll, updater.exe, etc.

The external files are stuff like:
  "Firefox Setup.exe" "complete.mar" etc.

Details on how the package will be presented to the signingworkers will be coming, via :mshal's work in Bug 1360525

(Sending mike a n-i to get that format entered here), current theory is that we'll use the .zip package from the Build.

Comment 1

[Michael Shal [:mshal]]

My current thought is that the .zip passed into the 1st stage of signing (internal signing) will look like a normal Windows .zip:

firefox/application.ini
firefox/firefox.exe
firefox/xul.dll
firefox/browser/omni.ja
(etc)

with the exception that I'll be adding the setup.exe files for the installer and stub installer at the top-level:

firefox/application.ini
firefox/firefox.exe
firefox/xul.dll
firefox/browser/omni.ja
...
setup.exe
setup-stub.exe

The internal signing process should be able to unzip the package and recursively sign the DLLs and exes (so this would automatically include the setup.exe & setup-stub.exe) using a process similar to how we call signtool.py now:

 python signtool.py  -f sha2signcode -i '*.dll' -i '*.exe' -x 'D3DCompiler*.dll' -x 'msvc*.dll'

So *.dll and *.exe are included, but certain dlls are excluded. I assume the exclusion list will need to be in tree somewhere so that it can be updated if necessary.

Note this is subject to change in case any complications come up, but this is the format I'm trying to work with so far.

Comment 2

[Michael Shal [:mshal]]

On second thought, do we have to send only a single file to the signing task? Or we can just output firefox.zip, setup.exe, and setup-stub.exe all to the signing task directly? This would simplify the build task if we could do the latter, I think.

Comment 3

[Aki Sasaki (not active)]

(In reply to Michael Shal [:mshal] from comment #2)
> On second thought, do we have to send only a single file to the signing
> task? Or we can just output firefox.zip, setup.exe, and setup-stub.exe all
> to the signing task directly? This would simplify the build task if we could
> do the latter, I think.

Currently we can send N files to the signing task; each can be signed in specified format(s).

    "upstreamArtifacts": [{
      "taskId": "upstream-task-id1",
      "taskType": "build",
      "paths": ["public/artifact/path1", "public/artifact/path2"],
      "formats": [...]
    }, {
      "taskId": "upstream-task-id2",
      "taskType": "build",
      "paths": ["public/artifact/path3", "public/artifact/path4"],
      "formats": [...]
    }, {
        ...
    }],

We can duplicate taskIds, although we may hit some weirdness if we specify the same path for the same taskId multiple times.

I imagine we'll have to define a couple signing formats for Windows.  One will be extract-zip-sign-contents-return-zip; another will be sign-exe.  I'm not sure if we need more variants.

Comment 4

[Michael Shal [:mshal]]

FYI, I think you can grab the files required from an existing Windows build from the following locations:

package: obj-firefox/dist/firefox-55.0a1.en-US.win32.zip (or win64.zip, etc)
setup.exe: obj-firefox/browser/installer/windows/instgen/setup.exe
setup-stub.exe: obj-firefox/browser/installer/windows/instgen/setup-stub.exe

We may want to change how the setup.exe's are generated in the future, and possibly where they wind up, but we could do grab those now for testing the internal signing bits.

Note that the stub installer is only done for particular builds: https://dxr.mozilla.org/mozilla-central/source/browser/confvars.sh#16

ie: 32-bit opt only, and only for particular update channels. I believe the regular installer is enabled for all Windows builds.

Comment 5

[Aki Sasaki (not active)]

Resolved in bug 1368192.