You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After configuring an application to sign with a new OV code signing certificate on a YubiKey 5 FIPS device, the build process prompts for the code signing PIN seven times. This occurs because signtool.exe is used to sign code, which triggers a prompt each time it is called. When there are multiple applications to sign, the bundler calls signtool.exe multiple times.
Describe the solution you'd like
The dream solution would be to leverage a pkcs11 interface library like cryptoki or native-pkcs11 to open a code signing session and persist that session while signing everything that needs to be signed, build the installers, and sign the installers before closing the session. Then the PIN could be supplied as an environment variable or entered a single time at a prompt in the terminal, avoiding the dialog on Windows entirely. This would also be cross-platform compatible because the pkcs11 libraries are cross-platform.
My suggestion would be to add pkcs11 to the list of keys in WindowsConfig and use that to indicate the path of the pkcs11 device. If present, that could trigger the use of pkcs11 code signing. If absent, the existing flow with signtool.exe could remain, but hopefully with a reduced number of calls to sign multiple files the minimum number of times possible, reducing the number of PIN prompts as much as possible.
Alternatives considered
Sign multiple files with each call to signtool.exe. This would reduce the number of prompts to two, I assume. First for anything that needs to be signed before going into an installer, then once again for the installers.
Custom signing script. This was proposed by @amrbashir in a comment on an open pull request that would add AzureSignTool support. Custom script support will open the door for unique project needs, but the common workflow should not depend on a custom signing script. As old OV code signing certificates expire, more people will be renewing to certificates stored on HSM devices that support pkcs11, but signtool.exe will always prompt each time it is called on Windows.
Switch the main workflow from signtool.exe to a tool that can support automated code signing. osslsigncode looks like a viable alternative as a tool, but it doesn't have a Windows installer. Maybe it could be automatically downloaded by the Tauri bundler, along with its dependencies, the way WIX is downloaded.
Additional context
Windows code signing currently depends on signtool.exe, which is not guaranteed to be present in any environment, certainly not on Linux. Switching to a pkcs11 library has the potential of opening up Windows application bundling on any platform supported by the install system, which could simplify the build pipeline for some cross-platform applications.
I'm willing to work this up into a pull request, depending on what direction the Tauri developers would want it to go.
The text was updated successfully, but these errors were encountered:
Describe the problem
After configuring an application to sign with a new OV code signing certificate on a YubiKey 5 FIPS device, the build process prompts for the code signing PIN seven times. This occurs because
signtool.exe
is used to sign code, which triggers a prompt each time it is called. When there are multiple applications to sign, the bundler callssigntool.exe
multiple times.Describe the solution you'd like
The dream solution would be to leverage a pkcs11 interface library like
cryptoki
ornative-pkcs11
to open a code signing session and persist that session while signing everything that needs to be signed, build the installers, and sign the installers before closing the session. Then the PIN could be supplied as an environment variable or entered a single time at a prompt in the terminal, avoiding the dialog on Windows entirely. This would also be cross-platform compatible because the pkcs11 libraries are cross-platform.My suggestion would be to add
pkcs11
to the list of keys inWindowsConfig
and use that to indicate the path of the pkcs11 device. If present, that could trigger the use of pkcs11 code signing. If absent, the existing flow withsigntool.exe
could remain, but hopefully with a reduced number of calls to sign multiple files the minimum number of times possible, reducing the number of PIN prompts as much as possible.Alternatives considered
signtool.exe
. This would reduce the number of prompts to two, I assume. First for anything that needs to be signed before going into an installer, then once again for the installers.signtool.exe
will always prompt each time it is called on Windows.signtool.exe
to a tool that can support automated code signing.osslsigncode
looks like a viable alternative as a tool, but it doesn't have a Windows installer. Maybe it could be automatically downloaded by the Tauri bundler, along with its dependencies, the way WIX is downloaded.Additional context
Windows code signing currently depends on
signtool.exe
, which is not guaranteed to be present in any environment, certainly not on Linux. Switching to apkcs11
library has the potential of opening up Windows application bundling on any platform supported by the install system, which could simplify the build pipeline for some cross-platform applications.I'm willing to work this up into a pull request, depending on what direction the Tauri developers would want it to go.
The text was updated successfully, but these errors were encountered: