packaging/signing

[giscus[bot]]

packaging/signing

Code signing is an essential part of application distribution. On Windows, applications without code signatures are likely to be flagged as viruses. On OSX, codesigning and Notarization is required before your application can be run by users.

https://docs.velopack.io/packaging/signing

[Mrxx99]

Can this be used with https://github.com/azure/trusted-signing-action?

[caesay]

No, it can't be used with that github action. Velopack generates binaries during the packaging process which need to be signed incrementally. Velopack can be used with Azure Trusted Signing using the SignTool integration. Please follow the instructions available here in the Azure Trusted Signing documentation

[viktor-safar-geodata]

It took me 50+ attempts to get this working so I thought I'd share my results. I have a Devops Release pipeline that does the signing via Azure Trusted Signing which is added as a Service Connection.

First error was that 'http://timestamp.acs.microsoft.com' is not a valid URL.
Next problem, signtool was ignoring the dlib param and was looking for certs on the system.
After some testing it lead me to believe that --signparams are not correctly passed when invoking signtool from within vpk.

Next error: SignTool Error: SignedCode::Sign returned error: 0x80070057

At this point I started installing my own signtool as per MS docs https://learn.microsoft.com/en-us/azure/trusted-signing/how-to-signing-integrations :

nuget install Microsoft.Windows.SDK.BuildTools -ExcludeVersion -OutputDirectory "$(Agent.ToolsDirectory)"

and ensuring it is the one to be used:

# Base directory to search
$basePath = "$(Agent.ToolsDirectory)\Microsoft.Windows.SDK.BuildTools"
# Search for signtool.exe within any version folder
$signtoolPath = Get-ChildItem -Path $basePath -Recurse -Filter "signtool.exe" -ErrorAction SilentlyContinue | Where-Object { $_.FullName -match "\\x64\\signtool\.exe$" } |
Select-Object -ExpandProperty FullName -First 1
# Check if signtool.exe was found
if ($signtoolPath) {
Write-Output "Found signtool.exe at: $signtoolPath"
Write-Host "##vso[task.setvariable variable=signtoolPath]$signtoolPath"
} else {
Write-Output "signtool.exe not found."
}

Next problem was authentication to Azure. Read a number of articles ( https://melatonin.dev/blog/code-signing-on-windows-with-azure-trusted-signing/ ) suggesting setting env variables like ARM_CLIENT_ID or AZURE_CLIENT_ID and others and that signtool will look for them. Could not get this to work. Until in the end I found this post https://serverfault.com/questions/1163621/signtool-exe-hangs-on-submitting-digest-for-signing-when-running-in-azure-d and moved my script into Azure CLI with Powershell and it finally started working

Ensure to check Access service principal details in script (or set addSpnToEnvironment: true if you're in YAML)

vpk pack `
--packId MyApp `
--packVersion $(MyVersion) `
--packDir "$(directory)" `
--mainExe "MyApp.exe" `
--packTitle "My app" `
--verbose `
--signTemplate "$(signtoolPath) sign /v /debug /fd SHA256 /tr `"`"`"http://timestamp.acs.microsoft.com`"`"`" /td SHA256 /dlib `"`"`"$(MtscDlib)`"`"`" /dmdf `"`"`"$(trustedSigningJsonPath)`"`"`" {{file...}}"

The insane backtick triple double quote is there because

• you need triple double quote for CMD to preserve a double quote (vpk starts a CMD.exe which calls signtool.exe with params, or your template)
• you need the backtick to escape the double quote in PS

The JSON manifest for Trusted Signing also had an issue. I create it within the pipeline using PS. Default implementation of UTF8 encoding in PS/.NET is with BOM. That causes an exception in the DLIB. The correct encoding (UTF8 no BOM) can be created with .NET like so:

$jsonObject = @{
Endpoint = "https://weu.codesigning.azure.net"
CodeSigningAccountName = "[account name]"
CertificateProfileName = "[profile name]"
}
$jsonContent = $jsonObject | ConvertTo-Json -Depth 10
$trustedSigningJsonPath = "$(trustedSigningJsonPath)"
$Utf8NoBomEncoding = New-Object System.Text.UTF8Encoding $False
[System.IO.File]::WriteAllText($trustedSigningJsonPath, $jsonContent, $Utf8NoBomEncoding)
Write-Output "JSON file created at $(trustedSigningJsonPath)"

[sgacond]

Thanks for these great docs! But I think i found a little issue...

I tried to adopt your github action sample and notarization failed with missing credentials even when they were set successfully.
In the store-credentials step xcrun notarytool store-credentials ... the --keychain ... parameter seems to be needed too. Otherwise, the notarization failed because the credentials were not found.

This is how it worked for me:
xcrun notarytool store-credentials --apple-id "$APPLE_ID" --team-id "$APPLE_TEAM" --password "$APPLE_PASSWORD" --keychain $KEYCHAIN_PATH velopack-profile

[IamBiswajitSahooOfficial]

How much time does it take on your side to sign and notarise the app bundle on Github macOS-latest runner. For me it's always staying stuck in Begin code signing step, despite allowing velopack full access to the certificates in the temporary keychain.

[sgacond]

I just checked the latest few builds and the velopack-build (incl. signing and notarization) is usually around 2-3 Minutes:

[tealblu]

Is there a way to reduce the number of files signed during packaging? My team has a limited number of signatures available, and packaging once consumes upwards of 25 signatures, which is not acceptable for our use case. Is it possible to sign the entire packaged version post-packaging?

[caesay]

The exe's in your package need to be signed if you want to avoid smartscreen, so that includes the Update.exe bundled by Velopack, your main application, the final setup exe, etc. By default all PE executables (dll's and exes) are signed. You can exclude any files you want using --signExclude.

For example, to skip all dll's:
vpk pack ... --signExclude ".*\.dll$"

[tealblu]

i see, i'll look into that, thanks! just to confirm, i don't need to sign the dlls? only the Update.exe from Velopack, my application, the setup exe, and any other exe's that need to be executed? thanks again

[caesay]

You should sign everything, which is why Velopack does that by default. But if you want to ignore that advice, just signing the exe's should be enough to get you around smartscreen warnings.