Simplifying signing integration for Trusted Signing

IanCS_MSFT

Microsoft

Nov 19, 2024

One of the biggest challenges for developers is the integration of signing into their workflows, and with Trusted Signing, we aim to make that easier and simpler to do by bringing integration into the developer tool chains and CI/CD pipelines.

One of the biggest challenges for developers is the integration of signing into their workflows, and with Trusted Signing, we aim to make that easier and simpler to do by bringing integration into the developer tool chains and CI/CD pipelines. We started with targeting the common tools used today for code signing Windows apps with the Windows SDK SignTool.exe integration, and covered CI/CD pipelines with the Trusted Signing Azure DevOps Extension and the Trusted Signing GitHub Action. These integrations are great options for developers familiar with signing, but developers are still required to understand what to sign in the production of their app and the package they use to distribute their application. Developers must orchestrate the signing of loose binaries before the packaging project kicks off and packages the binaries into an installer package.

During the Trusted Signing Preview, we observed not only many solution patterns being used by the early subscribers, but also subscribers sharing their solutions and supporting each other. This was a microcosm of the broader developer community that is always supportive of one another in the ecosystem. The sharing of simplification leads to a reduction of time spent on setting up and configuring signing solutions. This in turn leads to developers having more time to do things they couldn’t previously prioritize. We witnessed some of those opportunities where the time and effort saved in working on signing solutions turned into new features and new changes that have been on the proverbial back burner, in some cases for many years. We are happy to see that some of those simplification solutions for signing with Trusted Signing are now released for all subscribers to leverage, and we want to highlight some of those simplifications with you now.

Simplified SignTool Plugin (Dlib) Setup

During the Preview stages of Trusted Signing, we recognized the challenges of setting up our Windows SDK SignTool.exe plugin with all of its dependencies to be more time consuming for customers. Even though the setup is typically a one-time exercise, we wanted to simplify this to make it easier for customers. Today we are happy to announce that we’ve released the Trusted Signing Client Tools Installer. The Trusted Signing Client Tools Installer is simply an MSI package that installs the latest version of the Microsoft.Trusted.Signing.Client, the latest compatible Windows SDK SignTool.exe, latest .NET runtime, and all necessary Visual C++ dlib dependencies.

Figure 1: Trusted Signing Client Tools Installer.

We took it a step further and listed the Trusted Signing Client Tools in the Windows Package Manager (WinGet), making it easy to download and install from a single PowerShell command that strongly enforces the package ID (using -e parameter):

winget install -e --id Microsoft.Azure.TrustedSigningClientTools

For anyone not using WinGet, a slightly more complex PowerShell method may be used to quietly download and invoke the MSI as shown in the example here (run as administrator):

$ProgressPreference = 'SilentlyContinue'; Invoke-WebRequest -Uri "https://download.microsoft.com/download/6d9cb638-4d5f-438d-9f21-23f0f4405944/TrustedSigningClientTools.msi" -OutFile .\TrustedSigningClientTools.msi; Start-Process msiexec.exe -Wait -ArgumentList '/I TrustedSigningClientTools.msi /quiet'; Remove-Item .\TrustedSigningClientTools.msi

For all the details on how to download and install the Trusted Signing Client Tools, visit our Set up signing integrations to use Trusted Signing | Microsoft Learn documentation.

Trusted Signing Integration into dotnet/Sign

The dotnet/sign: Code Signing CLI tool supporting Authenticode, NuGet, VSIX, and ClickOnce (github.com) has a growing popularity among the developer community for it ease of use for bringing the signing operations of many tools under one Cli experience. Integration with Trusted Signing has been part of the service roadmap, and we piloted a PoC integration during our Private Preview with a few customers. With the Public Preview launch for Trusted Signing, the demand for the integration of the service into the dotnet/Sign project grew (Support for Azure Trusted Signing · Issue #683), and being an OSS project, we’ve collaborated with OSS developers who wanted to contribute to delivering this integration. Most notably was the contribution by Dirk Lemstra, a well-recognized OSS contributor and one of the maintainers of the ImageMagick and other related projects. Dirk's collaboration and contributions were instrumental in delivering the support for Trusted Signing in dotnet/Sign. Dirk published his story in the post, Signing NuGet packages with Trusted Signing, and he continues to pursue support in NuGet.org with a pull request on the NuGet project here for all to review and share their perspective.

The results of the integration in the dotnet/Sign Cli were first made available in pre-release version sign 0.9.1-beta.24325.5 and we’ve started working on integrating the dotnet/Sign Cli into our Trusted Signing GitHub Action and Azure DevOp Pipeline Extension to make it even simpler to integrate signing of NuGet, VSIX, and ClickOnce into these CI/CD pipelines.

To install dotnet/Sign, you'll need to run the .NET Tool and specify the version of the Sign Cli as shown in this example:

dotnet tool install --global sign --version 0.9.1-beta.24325.5

Once installed, to execute the sign cli it's just a matter of running a command. Here is an example script that can be used to measure how much time it takes to sign N files, and you can see there is a concurrency parameter that could be adjusted for your needs:

 [CmdletBinding()]
 param (
     [string]
     $endpoint = " https://region.codesigning.azure.net/", #Your Trusted Signing Account URI
     [string]
     $signaccount = "account", #Your Trusted Signing Account Name
     [string]
     $signprofile = "profile", #Your Trusted Signing Certificate Profile Name
     [string]
     $basePath = "C:\temp",
     [string]
     $filter = "**/*.exe",
     [int]
     $maxConcurrency = 5
 )
$start = Get-date
Write-Host $start
sign.exe code trusted-signing -tse $endpoint -tsa $signaccount -tscp $signprofile -b $basePath $filter -m $maxConcurrency
$end = Get-Date
$duration = New-TimeSpan -Start $start -End $end
Write-Host $duration

For more information on dotnet/Sign and to engage with the community on the project, visit the GitHub project, dotnet/sign: Code Signing CLI tool supporting Authenticode, NuGet, VSIX, and ClickOnce.

Advanced Installer makes packaging with signing built in

For any developer, packaging their application into an installer media type includes common steps of building the binaries and packaging them. The packaging steps can be solved with packaging projection solutions such as Caphyon's Advanced Installer product. The Advanced Installer team recognized that having signing built into the packaging project tooling was a great way to simplify the signing process and remove the need for custom orchestration. The Advanced Installer team announced, “Trusted Signing Integration: Advanced Installer's Newest Standard” where Trusted Signing is integrated into the packaging process, so binaries are signed before packaging and the package itself is signed automatically as well. Making the multiple step process now a single step process.

We, in the Trusted Signing team, recognized this integration into Advanced Installer as a powerful option for app developers, and during our Private Preview we saw an opportunity to share the Advanced Installer solution with the popular OSS project, ImageMagick. ImageMagick's signing challenges were well documented in late October 2023, when a maintainer for ImageMagick, Dirk Lemstra, shared on the project's GitHub Discussions that they will no longer be signing their Windows installer. The day of that Discussion post by Dirk led to a number of existing Trusted Signing Private Preview subscribers reaching out to see if we could help the ImageMagick project, and in week we had ImageMagick up and running with Trusted Signing. One of the challenges Dirk noted when working with us was the installer story for ImageMagick on Windows included 17 separate InnoSetup EXE installers, each being around 20MB in size. We connected Dirk with the folks at Advanced Installer, and they worked together to not only simplify the packaging and signing process for ImageMagick, but also modernized the installer by producing an MSIXBundle for ImageMagick on Windows that is less than 19 MB in size, and ImageMagick is now available on WinGet. The full story from Dirk and ImageMagick can be found here: ImageMagick MSIX installer now uses Trusted Signing.

More options and looking forward

The Advanced Installer feature with Trusted Signing integration wasn't the only development where Trusted Signing subscribers simplified signing and shared their solution. Some of the others we'd like to call out include:

They may be more out there, and we applaud the community engagement and interest.

The Trusted Signing team does provide a few components that we hope invites and encourages more developer community driven solutions. These components include:

Trusted Signing Crypto Provider (.NET) - simplifies the integration into existing tooling
Trusted Signing SDKs
- Trusted Signing Developer SDK
- Trusted Signing Resource Manager SDK

Going forward, Trusted Signing will be launching more integration options and enhancing existing integrations we support to deliver on our goals to make signing easier and simpler for all. If you want to discuss opportunities for collaboration on integrations with Trusted Signing, please reach out to us.