Download & releases

IceTrackVault ships Windows and Linux installers. macOS builds are not published or maintained as part of releases today.

Pre-built installers are published as GitHub Release assets:

github.com/NathanMeyersVO/IceTrackVault/releases

1. Windows: download the latest installer (.msi and/or .exe setup). Installers are Authenticode-signed via Azure Artifact Signing. Microsoft SmartScreen may still show a warning on brand-new releases until the certificate and files build reputation.
2. Linux: download the .deb (Debian and Ubuntu) or the .AppImage. Linux packages are not code-signed.

A local macOS build may be possible, but that is not a current priority. The author welcomes help from any interested macOS developer who would like to take on enabling macOS—see Build from source and GitHub.

Maintainers — ship a new version

1. Bump the same version in src-tauri/tauri.conf.json, src-tauri/Cargo.toml, and package.json.

2. Commit on main and push.

3. Tag and push the tag (triggers the Release workflow):

   git tag v1.0.0
   git push github v1.0.0

4. In GitHub Actions, wait for the Release workflow to finish.

5. Open the new draft release under Releases, verify the Windows assets (.msi / .exe) and the Linux assets (.deb / .AppImage), then Publish release.

Use tag names like v1.0.0 that match the app version 1.0.0.

Maintainers — code signing (Azure OIDC)

Release builds sign Windows binaries and installers during tauri build using Azure Artifact Signing, azure/login (OIDC), and src-tauri/sign-windows.ps1 (signtool + the Artifact Signing client DLL), configured in the Release workflow (see .github/workflows/release.yml). Linux .deb and .AppImage packages from the same workflow are not code-signed.

GitHub Actions secrets

Secret	Purpose
AZURE_CLIENT_ID	App registration (service principal) client ID
AZURE_TENANT_ID	Microsoft Entra tenant ID
AZURE_SUBSCRIPTION_ID	Subscription that contains the Artifact Signing account
AZURE_SIGNING_ENDPOINT	Account endpoint (e.g. https://westus2.codesigning.azure.net)
AZURE_SIGNING_ACCOUNT	Artifact Signing account name
AZURE_SIGNING_PROFILE	Certificate profile name

Do not store AZURE_CLIENT_SECRET. The workflow uses OIDC federated credentials (id-token: write + azure/login@v2). The signing script relies on that az session; it does not use artifact-signing-cli, which always requires a client secret and performs its own az login --service-principal.

The Release job uses the GitHub environment named release so OIDC works for every v* tag without adding a new Entra federated credential per tag.

Azure and GitHub setup checklist

1. Artifact Signing account, endpoint, and certificate profile (Public Trust identity verification completed).

2. GitHub repo environment release (Settings → Environments).

3. App registration with a federated credential whose subject matches that environment:

   repo:NathanMeyersVO/IceTrackVault:environment:release

   Tag-scoped subjects (e.g. ref:refs/tags/v1.0.0) are only for one-off tests; routine releases use the environment subject above.

4. Artifact Signing Certificate Profile Signer role assigned to that service principal on the signing account.

5. Reader (or higher) on the subscription that hosts the Artifact Signing account, assigned to the same service principal. Without this, azure/login may fail with “No subscriptions found” even when OIDC and federated credentials are correct. The Release workflow also sets allow-no-subscriptions: true on the login step to avoid intermittent subscription-enumeration failures when subscription-id is provided.

After a release, verify signatures on a Windows machine:

Get-AuthenticodeSignature .\path\to\*-setup.exe

Further reading: Tauri — Windows code signing (Azure Artifact Signing), Azure OIDC from GitHub Actions.