feat(release): sign Windows artifacts with Azure - #141
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe desktop release now uses separate build, package, and stage phases. The workflow signs Windows binaries and the installer with Azure-based Authenticode signing, verifies signatures, and publishes only from ChangesDesktop release pipeline
Estimated code review effort: 4 (Complex) | ~45 minutes Merge Risk: ⚪ Minimal · up to The release changes are merge-ready after normal checks and review; no actionable merge-blocking risk remains. Sequence Diagram(s)sequenceDiagram
participant GitHubActions
participant release_desktop.ps1
participant AzureOIDC
participant ArtifactSigning
participant AuthenticodeVerification
GitHubActions->>release_desktop.ps1: Run build phase
GitHubActions->>AzureOIDC: Authenticate with OIDC
GitHubActions->>ArtifactSigning: Sign release binaries
GitHubActions->>release_desktop.ps1: Run package phase
GitHubActions->>ArtifactSigning: Sign installer
GitHubActions->>AuthenticodeVerification: Verify signatures
GitHubActions->>release_desktop.ps1: Run stage phase
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (4 skipped: 4 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis change adds Azure OIDC-based signing to the Windows desktop release workflow. Release executables and DLLs are signed before updater hashes are generated, installers are signed and checked before the workflow publishes them, and releases started from non-main branches stop before Azure login. The hosted release path has the intended protections, but the local prerelease publishing script can still publish an installer without Azure signing or Authenticode validation. T-Rex validation blockedLive Windows signing and Authenticode verification could not run because the environment is missing the Windows runner service and Windows PowerShell/Authenticode tools. Control-flow and ordering checks were executed instead. Configure VMs Confidence Score: 4/5The hosted Windows release workflow is protected, but the local prerelease publishing route can expose an unsigned installer. Executable ordering and cross-script reachability checks verified all investigated release paths. Native Windows signing and Authenticode validation could not run without a Windows environment, but the local publication bypass is directly established by the release scripts. Files Needing Attention: scripts/publish_prerelease_local.ps1, scripts/release_desktop.ps1, and scripts/build_desktop_release.ps1 need a mandatory signing-validation gate or publication restriction.
|
Summary
Verification
fvm flutter analyze --no-fatal-infospasses with one pre-existing deprecation infomain: https://github.com/SunkenInTime/icarus/actions/runs/31983055496The release workflow is intentionally restricted to manual dispatches from
main, matching the federated credential.