electron-builder: Unable to sign NSIS

  • Electron-Builder Version: 24.11.0
  • Node Version: 19.8.2
  • Electron Version: 28.1.4
  • Electron Type (current, beta, nightly): current
  • Target: nsis (x64)

I am tryingg to build our Windows app in Docker, however I am always getting the following signing error:

⨯ Exit code: 255. Command failed: /root/.cache/electron-builder/winCodeSign/winCodeSign-2.6.0/linux/osslsigncode -in **REDACTED**E.exe -out **REDACTED**-signed-sha256.exe -t http://timestamp.digicert.com -pkcs12 ./build/**REDACTED**.p12 -h sha256 -n **REDACTED** -i **REDACTED** -nest -pass **REDACTED** (sha256 hash) to extract existing signature in -nest mode

We are using gitlab, here is the part ofthe .gitlab.yml

Windows:
    stage: build
    tags:
        - docker
    image: electronuserland/builder:wine
    script:
        - yarn
        - yarn run gsf:download --secretId 6 -o apps/raptor-electron # downloads the electron-builder.env
        - yarn workspace @**REDACTED**/raptor-electron run compile -w # Here it stops with the exception
        - mv 'apps/raptor-electron/dist/**REDACTED**.exe' './'
        - mv 'apps/raptor-electron/dist/**REDACTED**.exe.blockmap' './'
        - yarn workspace @**REDACTED**/raptor-electron run compile:appx
        - mv 'apps/raptor-electron/dist/**REDACTED**.appxbundle' './'
    artifacts:
        paths:
            - **REDACTED**.exe
            - **REDACTED**.exe.blockmap
            - **REDACTED**.appxbundle
    rules:
        - if: $NIGHTLY =~ /raptor/
          when: on_success
        - changes:
              - apps/raptor/**/*
              - apps/raptor-electron/**/*
          when: on_success

I first thought that the password of the Certificate file is wrong, but it is verified and correct. We are using the electron-builder.env file in the projects root directory which is downloaded by the build script. As a key for the Certificate File I am using WIN_CSC_KEY_PASSWORD

The job is executed on a Debian Machine

About this issue

  • Original URL
  • State: open
  • Created 6 months ago
  • Comments: 36 (11 by maintainers)

Most upvoted comments

Bingo, I think I can investigate further from here. But maybe a minimum reproducible repo would also help as the unit tests are super complex and a vanilla repo would probably really help here. Would you be willing to put one together?

https://github.com/electron-userland/electron-builder/actions/runs/7729511593/job/21072858970?pr=8023

  ● sign nested asar unpacked executables
    Error: expect(received).toContain(expected) // indexOf
    Expected substring: "This file format cannot be signed because it is not recognized."
    Received string:    "Exit code: 255. Command failed: /root/.cache/electron-builder/winCodeSign/winCodeSign-2.6.0/linux/osslsigncode -in /tmp/et-db411cd21f3bbd882f3a5a30c58db6ff/t-aczwLS/test-project-0/dist/win-unpacked/Test App ßW.exe -out /tmp/et-db411cd21f3bbd882f3a5a30c58db6ff/t-aczwLS/test-project-0/dist/win-unpacked/Test App ßW-signed-sha256.exe -t http://timestamp.digicert.com -pkcs12 /tmp/et-db411cd21f3bbd882f3a5a30c58db6ff/t-aczwLS/1.p12 -h sha256 -n Test App ßW -i http://foo.example.com -nest
    Unable to extract existing signature in -nest mode
    
    Failed
    
    Unable to extract existing signature in -nest mode

@Slapbox I didn’t further investigate this as i currently have to prioritize other things at work.

Tho I’d definitely like to help investigate this if someone needs information.

Fixed in v24.13.3 Apologies for any frustrations this caused and thanks for your patience!

It doesn’t appear that changing the config there is respected…

  • loaded configuration  file=/Users/beau/p/meris-editor/electron-builder.json5
  • writing effective config  file=release/1.0.6/builder-effective-config.yaml
  • rebuilding native dependencies  dependencies=@julusian/midi@3.2.0 platform=win32 arch=x64
  • rebuilding native dependency  name=@julusian/midi version=3.2.0
  • packaging       platform=win32 arch=x64 electron=28.2.3 appOutDir=release/1.0.6/win-unpacked
  • signing         file=release/1.0.6/win-unpacked/Meris prEDITOR.exe certificateFile=/Users/beau/p/meris-editor/beau-gunderson.pfx
{ platform: 'darwin', isNest: false }
{ platform: 'darwin', isNest: false }
  ⨯ Exit code: 255. Command failed: /Users/beau/Library/Caches/electron-builder/winCodeSign/winCodeSign-2.6.0/darwin/10.12/osslsigncode -in /Users/beau/p/meris-editor/release/1.0.6/win-unpacked/Meris prEDITOR.exe -out /Users/beau/p/meris-editor/release/1.0.6/win-unpacked/Meris prEDITOR-signed-sha256.exe -t http://timestamp.digicert.com -pkcs12 /Users/beau/p/meris-editor/beau-gunderson.pfx -h sha256 -n Meris prEDITOR -i https://github.com/beaugunderson/meris-editor -nest -pass acdb1c392c6e5213165aa2d57bdf655f19ee1d8cb3b9e4129a6086cd97b06016 (sha256 hash) to extract existing signature in -nest mode
Failed

Unable to extract existing signature in -nest mode

I used a modified version that prints the values:

module.exports = async function sign(config, packager) {
  config.isNest = process.platform === 'win32' ? config.isNest : false;
  console.log({ platform: process.platform, isNest: config.isNest });
  await doSign(config, packager)
}

@Slapbox I will try to verify it by changing electronuserland/builder:wine to electronuserland/builder:18-wine

Regarding the electron-builder.env

It obviously doesn’t look exactly like this, I do have the following keys defined WIN_CSC_KEY_PASSWORD, APPLE_API_KEY, APPLE_API_KEY_ID, APPLE_API_KEY_ISSUER, we use a .p12 format, as we did in our currently running project.

The currently running project uses a very old version electron-builder and is build on a macMini with Paralels Desktop.

Can you give this sign.js script for win.sign config as a test of my current assumption?

const { doSign } = require('app-builder-lib/out/codeSign/windowsCodeSign')

/**
 * @type {import("electron-builder").CustomWindowsSign} sign
 */
module.exports = async function sign(config, packager) {
  config.isNest = false
  await doSign(config, packager)
}

I think what isNest is doing is that it’s appending to file signatures, which don’t seem to exist within a docker image? Disabling isNext I think will bypass this and only update/create a signature