Skip to content

Remove inaccurate and redundant signing determination code from build system #2567

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 18, 2024

Conversation

per1234
Copy link
Contributor

@per1234 per1234 commented Nov 18, 2024

Motivation

The "build" workflow signs the macOS and Windows builds of the application. The signing process relies on access to GitHub Actions secrets. For this reason, the workflow is configured to only sign the builds when it has access to GitHub Actions secrets to avoid spurious failures of the workflow that would otherwise be caused by signing failure.

A flexible general purpose system for accurately determining whether to attempt signing of a build was established years ago (#1115) However, when the Windows signing system was reworked to support the new "eToken" hardware authenticator-based approach (#2452), that system was circumvented, causing workflow runs triggered by pull requests to fail spuriously (#2545). When this was later discovered, an inferior redundant system was added (#2554) specific to the Windows build instead of just using the existing system.

This redundant system determines whether to sign based on the value of the github.event.pull_request.head.repo.fork context item. That is effective for the use case of the workflow being triggered by a pull request from a fork (for security reasons, GitHub Actions does not give access to secrets under these conditions).

However, there is another context under which the workflow might run without access to the signing secrets, for which the use of context item is not appropriate. It is important to support the use of the workflow in forks of the repository. In addition to the possible value to hard forked projects, this is essential to allow conscientious contributors to test contributions to the build and release system in their own fork prior to submitting a pull request. The previous configuration would cause a workflow run performed by a contributor in a fork to attempt to sign the Windows build. Unless the contributor had set up the ridiculously complex infrastructure required to perform the signing for the Windows build (#2452), which is utterly infeasible, this would cause the workflow to fail spuriously:

Custom windows signing was no performed one of the following variables was not provided: SIGNTOOL_PATH (C:/Program Files (x86)/Windows Kits/10/bin/10.0.19041.0/x86/signtool.exe), INSTALLER_CERT_WINDOWS_CERT (C:/Users/RUNNER~1/AppData/Local/Temp/cert.cer), CERT_PASSWORD (), CONTAINER_NAME ()
file:///D:/a/arduino-ide/arduino-ide/electron-app/node_modules/execa/lib/error.js:60
		error = new Error(message);
		        ^

Error: Command failed with exit code 1: electron-builder --publish never -c.electronVersion 27.0.3 -c.extraMetadata.version 2.3.4 -c.extraMetadata.name arduino-ide -c.win.artifactName arduino-ide_2.3.4_Windows_64bit.${ext} -c.extraMetadata.theia.frontend.config.appVersion 2.3.4 -c.extraMetadata.theia.frontend.config.cliVersion 1.0.4 -c.extraMetadata.theia.frontend.config.buildDate 2024-11-16T13:27:51.643Z -c.extraMetadata.main ./arduino-ide-electron-main.js
    at makeError (file:///D:/a/arduino-ide/arduino-ide/electron-app/node_modules/execa/lib/error.js:60:11)
    at handlePromise (file:///D:/a/arduino-ide/arduino-ide/electron-app/node_modules/execa/index.js:124:26)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async exec (D:\a\arduino-ide\arduino-ide\electron-app\scripts\package.js:162:22)
    at async run (D:\a\arduino-ide\arduino-ide\electron-app\scripts\package.js:49:3) {
  shortMessage: 'Command failed with exit code 1: electron-builder --publish never -c.electronVersion 27.0.3 -c.extraMetadata.version 2.3.4 -c.extraMetadata.name arduino-ide -c.win.artifactName arduino-ide_2.3.4_Windows_64bit.${ext} -c.extraMetadata.theia.frontend.config.appVersion 2.3.4 -c.extraMetadata.theia.frontend.config.cliVersion 1.0.4 -c.extraMetadata.theia.frontend.config.buildDate 2024-11-16T13:27:51.643Z -c.extraMetadata.main ./arduino-ide-electron-main.js',
  command: 'electron-builder --publish never -c.electronVersion 27.0.3 -c.extraMetadata.version 2.3.4 -c.extraMetadata.name arduino-ide -c.win.artifactName arduino-ide_2.3.4_Windows_64bit.${ext} -c.extraMetadata.theia.frontend.config.appVersion 2.3.4 -c.extraMetadata.theia.frontend.config.cliVersion 1.0.4 -c.extraMetadata.theia.frontend.config.buildDate 2024-11-16T13:27:51.643Z -c.extraMetadata.main ./arduino-ide-electron-main.js',
  escapedCommand: 'electron-builder --publish never -c.electronVersion 27.0.3 -c.extraMetadata.version 2.3.4 -c.extraMetadata.name arduino-ide -c.win.artifactName "arduino-ide_2.3.4_Windows_64bit.${ext}" -c.extraMetadata.theia.frontend.config.appVersion 2.3.4 -c.extraMetadata.theia.frontend.config.cliVersion 1.0.4 -c.extraMetadata.theia.frontend.config.buildDate "2024-11-16T13:27:51.643Z" -c.extraMetadata.main "./arduino-ide-electron-main.js"',
  exitCode: 1,
  signal: undefined,
  signalDescription: undefined,
  stdout: undefined,
  stderr: undefined,
  cwd: 'D:\\a\\arduino-ide\\arduino-ide\\electron-app',
  failed: true,
  timedOut: false,
  isCanceled: false,
  killed: false
}

Node.js v18.17.1
error Command failed with exit code 1.

Change description

Remove the inferior and redundant signing determination code and use the previously established system for all targets.

This makes the workflow easier to understand and maintain.

Reviewer checklist

  • PR addresses a single concern.
  • The PR has no duplicates (please search among the Pull Requests before creating one)
  • PR title and description are properly filled.
  • Docs have been added / updated (for bug fixes / features)

…workflow

The "build" workflow signs the Windows builds of the application. The signing process relies on access to GitHub Actions
secrets. For this reason, the workflow is configured to only sign the builds when it has access to GitHub Actions
secrets to avoid spurious failures of the workflow that would otherwise be caused by signing failure.

Previously the signing was determined based on the value of the `github.event.pull_request.head.repo.fork` context item.
That was effective for the use case of the workflow being triggered by a pull request from a fork (for security reasons,
GitHub Actions does not give access to secrets under these conditions).

However, there is another context under which the workflow might run without access to the signing secrets, for which
the use of context item is not appropriate. It is important to support the use of the workflow in forks of the
repository. In addition to the possible value to hard forked projects, this is essential to allow conscientious
contributors to test contributions to the build and release system in their own fork prior to submitting a pull request.
The previous configuration would cause a workflow run performed by a contributor in a fork to attempt to sign the
Windows build. Unless the contributor had set up the ridiculously complex infrastructure required to perform the signing
for the Windows build, which is utterly infeasible, this would cause the workflow to fail spuriously.

The appropriate approach, which has been the established convention in the rest of the workflow code, is to use the
secret itself when determining whether to attempt the signing process. If the secret is not defined (resulting in it
having an empty string value), then the signing should be skipped. If it is defined, then the signing should be
performed.
The "build" workflow signs the macOS and Windows builds of the application. The signing process relies on access to GitHub Actions
secrets. For this reason, the workflow is configured to only sign the builds when it has access to GitHub Actions
secrets to avoid spurious failures of the workflow that would otherwise be caused by signing failure.

A flexible general purpose system for determining whether to attempt signing of a build was established years ago. However, a redundant system was added specific to the Windows build instead of using the existing system.

The redundant system is hereby removed. This makes the workflow easier to understand and maintain.
@per1234 per1234 added topic: infrastructure Related to project infrastructure os: windows Specific to Windows operating system type: imperfection Perceived defect in any part of project labels Nov 18, 2024
@per1234 per1234 self-assigned this Nov 18, 2024
@per1234 per1234 merged commit 4f8b980 into arduino:main Nov 18, 2024
22 checks passed
@per1234 per1234 deleted the signing-determination branch November 19, 2024 12:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
os: windows Specific to Windows operating system topic: infrastructure Related to project infrastructure type: imperfection Perceived defect in any part of project
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant