AppImage signing with GPG
AppImage binaries can be signed using gpg or gpg2 to increase trust in deployed applications. Generate a new GPG key using 'gpg2 --full-gen-key'. The private and public keys should be backed up securely.
building/code-signing
32 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
AppImage signing environment variables
Embed a signature in an AppImage using these environment variables: SIGN (set to 1 to sign), SIGN_KEY (optional, specifies GPG Key ID), APPIMAGETOOL_SIGN_PASSPHRASE (signing key password, required for CI/CD), and APPIMAGETOOL_FORCE_SIGN (set to 1 to exit on signing errors).
Display AppImage embedded signature
To display the signature embedded in an AppImage, run: ./src-tauri/target/release/bundle/appimage/$APPNAME_$VERSION_amd64.AppImage --appimage-signature, where $APPNAME and $VERSION must be replaced with actual values.
AppImage signature validation pitfall
AppImage does not validate the signature automatically, so it cannot verify whether a file has been tampered with. The user must manually verify the signature using the AppImage validate tool. The public key ID should be published on an authenticated channel (such as a TLS-served website) for users to verify.
Validate AppImage signature command
Download the AppImage validate tool from https://github.com/AppImageCommunity/AppImageUpdate/releases/tag/continuous by selecting a validate-$PLATFORM.AppImage file. Run: chmod +x validate-$PLATFORM.AppImage && ./validate-$PLATFORM.AppImage $TAURI_OUTPUT.AppImage. Successful validation outputs 'Validation result: validation successful' with the key fingerprint.
Linux code signing not required
Code signing for Linux packages is not required for deploying applications on Linux, though it is recommended to increase trust in the deployed application by allowing end users to verify authenticity and detect unauthorized modifications.
Obtain certificate thumbprint and digest algorithm from Windows certificate manager
Open Personal Certificate Management (certmgr.msc), navigate to Personal/Certificates, find the imported certificate, double-click it, and open the Details tab. The Signature hash algorithm provides the digestAlgorithm (typically sha256). Scroll down to Thumbprint to find the certificateThumbprint value.
Windows code signing configuration in tauri.conf.json
In tauri.conf.json, configure Windows code signing under tauri > bundle > windows with three fields: certificateThumbprint (the certificate's thumbprint hash), digestAlgorithm (typically sha256), and timestampUrl (a time server URL used to verify the certificate signing time, for example http://timestamp.comodoca.com).
Example Windows code signing configuration
```json "windows": { "certificateThumbprint": "A1B1A2B2A3B3A4B4A5B5A6B6A7B7A8B8A9B9A0B0", "digestAlgorithm": "sha256", "timestampUrl": "http://timestamp.comodoca.com" } ``` This example shows the three required configuration fields for Windows code signing in tauri.conf.json.
GitHub Actions secrets for Windows certificate signing
Two GitHub secrets are needed for automated Windows code signing: WINDOWS_CERTIFICATE (Base64 encoded version of the .pfx certificate file, created using certutil -encode certificate.pfx base64cert.txt) and WINDOWS_CERTIFICATE_PASSWORD (the certificate export password used when creating the .pfx file).
GitHub Actions workflow step to import Windows certificate
Add this workflow step before the build step to import the Windows certificate: ```yml - name: import windows certificate if: matrix.platform == 'windows-latest' env: WINDOWS_CERTIFICATE: ${{ secrets.WINDOWS_CERTIFICATE }} WINDOWS_CERTIFICATE_PASSWORD: ${{ secrets.WINDOWS_CERTIFICATE_PASSWORD }} run: | New-Item -ItemType directory -Path certificate Set-Content -Path certificate/tempCert.txt -Value $env:WINDOWS_CERTIFICATE certutil -decode certificate/tempCert.txt certificate/certificate.pfx Remove-Item -path certificate -include tempCert.txt Import-PfxCertificate -FilePath certificate/certificate.pfx -CertStoreLocation Cert:\CurrentUser\My -Password (ConvertTo-SecureString -String $env:WINDOWS_CERTIFICATE_PASSWORD -Force -AsPlainText) ``` This step creates a certificate directory, decodes the base64 certificate, and imports it into the certificate store.
Azure Key Vault certificate signing with relic
You can sign Windows executables using Azure Key Vault certificates with relic (a Go tool). Download relic from its releases page or run go install github.com/sassoftware/relic/v8@latest. Create a relic.conf file in the src-tauri folder and configure the bundle > windows > signCommand in tauri.conf.json to use relic.
Azure Key Vault relic configuration file format
Create a relic.conf file in src-tauri folder with this format: ```yml tokens: azure: type: azure keys: azure: token: azure id: https://<KEY_VAULT_NAME>.vault.azure.net/certificates/<CERTIFICATE_NAME> ``` Replace <KEY_VAULT_NAME> with your Azure Key Vault name and <CERTIFICATE_NAME> with your certificate name.
Azure Key Vault signCommand configuration in tauri.conf.json
Configure the bundle > windows > signCommand in tauri.conf.json to use relic: ```json { "bundle": { "windows": { "signCommand": "relic sign --file %1 --key azure --config relic.conf" } } } ```
Azure Key Vault relic authentication credentials
relic must authenticate with Azure to load the certificate. Set these environment variables: AZURE_CLIENT_ID (Application Client ID from App registrations), AZURE_TENANT_ID (Directory Tenant ID from App registrations), and AZURE_CLIENT_SECRET (client secret value created in Certificates & secrets). You must also assign the "Key Vault Certificate User" and "Key Vault Crypto User" roles to your application in the key vault's Access control (IAM) page.
Custom signCommand configuration for Tauri Windows signing
The bundle > windows > signCommand configuration option allows using any code signing tool that can sign Windows executables. This is required when cross-compiling Windows installers from Linux and macOS machines, as the default implementation only works on Windows.
Azure Artifact Signing (Azure Trusted Signing) for Windows code signing
You can sign Windows executables using Azure Artifact Signing (previously called Azure Code Signing/Azure Trusted Signing) certificates. This requires an Azure Artifact Signing Account with proper permissions, .NET 8, Azure CLI, Signtool (Windows 11 SDK 10.0.26100.0 or later recommended), and the artifact-signing-cli tool.
Install artifact-signing-cli
Install artifact-signing-cli using: cargo install artifact-signing-cli
Azure Artifact Signing environment variables
artifact-signing-cli requires these environment variables (should be added as GitHub Actions secrets): AZURE_CLIENT_ID (the client ID of your App Registration), AZURE_CLIENT_SECRET (the client secret of your App Registration), and AZURE_TENANT_ID (the tenant ID of your Azure directory).
Azure Artifact Signing tauri.conf.json configuration
Configure the bundle > windows > signCommand in tauri.conf.json: ```json { "bundle": { "windows": { "signCommand": "artifact-signing-cli -e https://wus2.codesigning.azure.net -a MyAccount -c MyProfile -d MyApp %1" } } } ``` Replace values: -e is the endpoint of your Azure Artifact Signing account, -a is the account name, -c is the certificate profile name, -d is the description (optional, used in UAC prompt or as random string if unset).
Windows code signing requirement for Microsoft Store and SmartScreen
Code signing is required on Windows to allow your application to be listed in the Microsoft Store and to prevent a SmartScreen warning that your application is not trusted and cannot be started when downloaded from the browser. However, it is not required to execute your application on Windows if your end user is okay with ignoring the SmartScreen warning or does not download via the browser.
OV certificates before June 1st 2023 require special handling
Code signing with OV (Organization Validated) certificates acquired before June 1st 2023 requires the specific procedures documented in this guide. For code signing with EV (Extended Validation) certificates and OV certificates received after June 1st 2023, consult the documentation of your certificate issuer instead.
EV vs OV certificate reputation with Microsoft SmartScreen
If you sign the app with an EV Certificate, it receives an immediate reputation with Microsoft SmartScreen and will not show any warnings to users. If you opt for an OV Certificate, which is generally cheaper and available to individuals, Microsoft SmartScreen will still show a warning to users when they download the app. It may take time until your certificate builds enough reputation. You may submit your app to Microsoft for manual review, and if the app does not contain malicious code, Microsoft may grant additional reputation and potentially remove the warning.
Windows code signing certificate requirements
You need a code signing certificate, not an SSL certificate. Code signing certificates can be acquired from services listed in Microsoft's documentation, though there are likely additional authorities for non-EV certificates.
Convert certificate from .cer to .pfx format
To convert a .cer certificate file to .pfx format, use the command: openssl pkcs12 -export -in cert.cer -inkey private-key.key -out certificate.pfx. You will be prompted to enter an export password which must be remembered for later use.
Import .pfx certificate into Windows keystore using PowerShell
To import a .pfx certificate into the Windows keystore, assign the export password to a variable using $WINDOWS_PFX_PASSWORD = 'MYPASSWORD', then run: Import-PfxCertificate -FilePath certificate.pfx -CertStoreLocation Cert:\CurrentUser\My -Password (ConvertTo-SecureString -String $WINDOWS_PFX_PASSWORD -Force -AsPlainText)
macOS App Store provisioning profile requirements
For App Store macOS distribution, the provisioning profile must be a 'Mac App Store Connect' profile. It must be created in the Profiles page after creating an App ID in the Identifiers page. The Bundle ID of the App ID must match tauri.conf.json > identifier. Configure the profile in tauri.conf.json > bundle > macOS > files > embedded.provisionprofile.
macOS App Store entitlements requirements
Apps distributed to the App Store must include the App Sandbox capability in entitlements. Create an Entitlements.plist file in src-tauri with com.apple.security.app-sandbox set to true, com.apple.application-identifier set to $TEAM_ID.$IDENTIFIER, and com.apple.developer.team-identifier set to $TEAM_ID. Reference this file in tauri.conf.json > bundle > macOS > entitlements. Replace $IDENTIFIER with tauri.conf.json > identifier value and $TEAM_ID with the Apple Developer team ID found in the App ID Prefix section.
macOS .pkg creation from app bundle
Generate a signed .pkg file from the app bundle using: xcrun productbuild --sign "<certificate signing identity>" --component "target/universal-apple-darwin/release/bundle/macos/$APPNAME.app" /Applications "$APPNAME.pkg". Replace $APPNAME with the actual app name. The PKG must be signed with a Mac Installer Distribution signing certificate.
Code signing is required on most platforms
Code signing enhances application security by applying a digital signature to executables and bundles, validating the identity of the application provider. Signing is required on most platforms, with platform-specific requirements documented separately for macOS, Windows, Linux, Android, and iOS.
Generate GPG key for RPM signing
Use `gpg --gen-key` to generate a GPG key for signing RPM packages. After generation, export the key to an environment variable: `export TAURI_SIGNING_RPM_KEY=$(cat /path/to/key)`. If the key has a passphrase, also set: `export TAURI_SIGNING_RPM_KEY_PASSPHRASE=password`. Then run the normal build command to sign the package during build.
Verify RPM package signature with rpm --checksig
Before verifying an RPM signature, export the public key with `gpg --export -a 'KeyName' > RPM-GPG-KEY-KeyName`, then import it to the RPM database with `sudo rpm --import RPM-GPG-KEY-KeyName`. Edit `~/.rpmmacros` to specify GPG settings including signature method, GPG path, key name, and GPG binary path. Then verify with: `rpm -v --checksig package_name.rpm`.