Open FlippingBinary opened 2 months ago
Hey thanks for the detailed issued and apologies for the late reply.
I think we should stick with what exists in OS so that would be signtool.exe
but the custom signing command https://github.com/tauri-apps/tauri/pull/9865 has landed and will be available in the next release, so I guess you could use that to suite your needs.
- 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.
I think this is probably the best way to go about solving this issue.
No worries. For my purposes, I'll probably just use a custom signing command and store the PIN so I don't have to manually enter it, but I already reduced the number of prompts by disabling the exe bundler since I only use msi.
However, I hope you'll still consider batching the assets to be signed so they can be passed to a single signing command. Like many signing tools, Microsoft's signtool.exe
will sign multiple assets at the same time if they are specified in the same command line and will prompt just once when doing so. Obviously, there would still be two sessions if an asset needs to be signed after creating it with a signed asset, but it would be hugely beneficial to anyone who wants the security of manually entering their PIN without the annoyance of doing it up to 7 times per build.
Yeah ofc we need to do some batching, I think that will reduce the pin entry to 3 times, one for binaries, another for uninstaller and last one for the installer
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.