ci(release): add Azure Trusted Signing for Windows builds #805
Conversation
- Integrated SENTRY_DSN, SENTRY_TRACES_SAMPLE_RATE, and SENTRY_PROFILES_SAMPLE_RATE as environment variables in the build steps of both beta-release.yml and release.yml workflows. - This enhancement ensures that Sentry monitoring is properly configured during application builds across different platforms (macOS, Windows, Linux). This change improves error tracking and performance monitoring capabilities for the application.
Integrate Azure Trusted Signing to sign Windows executables during release and beta-release workflows. This removes SmartScreen warnings for users downloading Auto-Claude on Windows. - Add OIDC authentication with Azure (no client secret needed) - Sign .exe files after packaging using azure/trusted-signing-action - Use North Europe endpoint (neu.codesigning.azure.net) - Conditionally skip signing if Azure credentials not configured Required GitHub secrets: AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_SUBSCRIPTION_ID, AZURE_SIGNING_ACCOUNT, AZURE_CERTIFICATE_PROFILE
|
Note Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported. |
github-actions
bot
added
🔄 Checking
|
Warning Rate limit exceeded@AndyMik90 has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 15 minutes and 12 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (2)
📝 Walkthrough📝 Walkthrough🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In @.github/workflows/beta-release.yml:
- Around line 328-336: The step-level if uses env.AZURE_CLIENT_ID which isn't
available when the expression is evaluated; change the condition on the "Azure
Login (OIDC)" step to evaluate the secrets context directly by replacing the if
with a workflow expression using secrets (e.g., if: ${{ secrets.AZURE_CLIENT_ID
!= '' }}), and keep the existing with: client-id/tenant-id/subscription-id
referencing secrets as-is so the step is correctly gated by the secret's
presence.
- Around line 338-351: The workflow uses an outdated GitHub Action version for
code signing: update the action reference azure/[email protected] to
azure/[email protected] in the Sign Windows executable step (the
action name string and the step title "Sign Windows executable with Azure
Trusted Signing") so the job uses the latest release; leave the existing env and
with keys (AZURE_CLIENT_ID conditional, endpoint, trusted-signing-account-name,
certificate-profile-name, files-folder, files-folder-filter, file-digest,
timestamp-rfc3161, timestamp-digest) unchanged.
In @.github/workflows/release.yml:
- Around line 264-287: The two workflow steps "Azure Login (OIDC)" and "Sign
Windows executable with Azure Trusted Signing" use if: env.AZURE_CLIENT_ID != ''
which fails because step env is not available when evaluating if; replace the
condition to check the secret directly (if: secrets.AZURE_CLIENT_ID != '') or
move AZURE_CLIENT_ID into a higher-level env (job/workflow) so the env is
available at evaluation time, and keep the existing step-level env entries only
for runtime use (ensure the step names "Azure Login (OIDC)" and "Sign Windows
executable with Azure Trusted Signing" are updated accordingly).
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/beta-release.yml.github/workflows/release.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Cursor Bugbot
- GitHub Check: CodeQL (python)
- GitHub Check: CodeQL (javascript-typescript)
🔇 Additional comments (5)
.github/workflows/beta-release.yml (2)
118-121: LGTM! Sentry environment variables correctly added.The Sentry configuration is appropriately sourced from secrets, allowing the build process to integrate error tracking without exposing sensitive values.
262-264: LGTM! Permissions correctly configured for OIDC.The
id-token: writepermission is required for Azure workload identity federation, andcontents: readprovides minimal access for checkout..github/workflows/release.yml (3)
67-70: LGTM! Sentry environment variables correctly added.Consistent with the beta-release workflow—Sentry configuration is properly sourced from secrets.
204-206: LGTM! OIDC permissions properly configured.Correctly mirrors the beta-release workflow with minimal required permissions.
261-262: LGTM! Correctly disables electron-builder's built-in signing.Disabling
CSC_IDENTITY_AUTO_DISCOVERYprevents conflicts with the Azure Trusted Signing step. The comment clearly explains the rationale.
| - name: Azure Login (OIDC) | ||
| if: env.AZURE_CLIENT_ID != '' | ||
| uses: azure/login@v2 | ||
| env: | ||
| AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }} | ||
| with: | ||
| client-id: ${{ secrets.AZURE_CLIENT_ID }} | ||
| tenant-id: ${{ secrets.AZURE_TENANT_ID }} | ||
| subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} |
There was a problem hiding this comment.
Conditional check may not work as intended.
The if: env.AZURE_CLIENT_ID != '' condition is evaluated before the step's env block is processed. The step-level env context isn't available in the if expression—it checks the job/workflow-level environment instead.
To properly gate on the secret's presence, use the secrets context directly:
Proposed fix
- name: Azure Login (OIDC)
- if: env.AZURE_CLIENT_ID != ''
+ if: ${{ secrets.AZURE_CLIENT_ID != '' }}
uses: azure/login@v2
- env:
- AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}🤖 Prompt for AI Agents
In @.github/workflows/beta-release.yml around lines 328 - 336, The step-level if
uses env.AZURE_CLIENT_ID which isn't available when the expression is evaluated;
change the condition on the "Azure Login (OIDC)" step to evaluate the secrets
context directly by replacing the if with a workflow expression using secrets
(e.g., if: ${{ secrets.AZURE_CLIENT_ID != '' }}), and keep the existing with:
client-id/tenant-id/subscription-id referencing secrets as-is so the step is
correctly gated by the secret's presence.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
AndyMik90
left a comment
AndyMik90
left a comment
There was a problem hiding this comment.
🤖 Auto Claude PR Review
Merge Verdict: 🔴 BLOCKED
🔴 Blocked - 4 critical/high/medium issue(s) must be fixed.
Blocked by 4 critical issues
Risk Assessment
| Factor | Level | Notes |
|---|---|---|
| Complexity | Low | Based on lines changed |
| Security Impact | None | Based on security findings |
| Scope Coherence | Good | Based on structural review |
🚨 Blocking Issues (Must Fix)
- Critical: Conditional check will always fail - Azure Login never executes (.github/workflows/release.yml:265)
- Critical: Conditional check will always fail - Windows signing never executes (.github/workflows/release.yml:276)
- Critical: Conditional check will always fail - Azure Login never executes (beta workflow) (.github/workflows/beta-release.yml:329)
- Critical: Conditional check will always fail - Windows signing never executes (beta workflow) (.github/workflows/beta-release.yml:340)
Findings Summary
- Critical: 4 issue(s)
- Low: 2 issue(s)
Generated by Auto Claude PR Review
Findings (6 selected of 6 total)
🔴 [318423d29c8c] [CRITICAL] Conditional check will always fail - Azure Login never executes
📁 .github/workflows/release.yml:265
The condition if: env.AZURE_CLIENT_ID != '' checks an environment variable defined in the step's own env: block (line 268). GitHub Actions evaluates the if: condition BEFORE processing the step's env: block. At evaluation time, env.AZURE_CLIENT_ID is undefined, so the condition always evaluates to '' != '' which is false. The Azure Login step will NEVER execute, even when secrets are properly configured.
Suggested fix:
Set the environment variable at job level instead of step level:
```yaml
build-windows:
runs-on: windows-latest
env:
AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
steps:
- name: Azure Login (OIDC)
if: env.AZURE_CLIENT_ID != ''
uses: azure/login@v2
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
...
#### 🔴 [1e90dd11600f] [CRITICAL] Conditional check will always fail - Windows signing never executes
📁 `.github/workflows/release.yml:276`
The condition `if: env.AZURE_CLIENT_ID != ''` on the signing step has the same bug as the Azure Login step. The `env.AZURE_CLIENT_ID` is only defined in this step's own `env:` block (line 278), which is not processed until after the `if:` condition is evaluated. The signing step will NEVER run, meaning Windows executables will be released UNSIGNED.
**Suggested fix:**
Set the environment variable at job level (same fix as finding-1). This single change at job level will fix both the Azure Login and Signing steps.
#### 🔴 [8cb3b2a62c99] [CRITICAL] Conditional check will always fail - Azure Login never executes (beta workflow)
📁 `.github/workflows/beta-release.yml:329`
Identical bug in beta-release.yml: The condition `if: env.AZURE_CLIENT_ID != ''` checks an environment variable defined in the step's own `env:` block (line 332). The `if:` condition is evaluated BEFORE the `env:` block is processed, so `env.AZURE_CLIENT_ID` will always be empty. The Azure Login step will NEVER execute in beta releases.
**Suggested fix:**
Set the environment variable at job level:
build-windows:
needs: create-tag
runs-on: windows-latest
env:
AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
permissions:
...
#### 🔴 [4e12e1fcfc85] [CRITICAL] Conditional check will always fail - Windows signing never executes (beta workflow)
📁 `.github/workflows/beta-release.yml:340`
Identical bug: The signing step condition `if: env.AZURE_CLIENT_ID != ''` references an env var from its own `env:` block (line 342). This will never evaluate to true, so beta Windows builds will never be signed.
**Suggested fix:**
Same fix as finding-3 - set the environment variable at job level.
#### 🔵 [8cb799ab4f2a] [LOW] Azure Trusted Signing action version is outdated
📁 `.github/workflows/release.yml:275`
The workflow uses `azure/[email protected]`, but the latest version is v0.5.11. While v0.5.1 should still work, updating to the latest version is recommended for bug fixes and improvements.
**Suggested fix:**
Update to the latest version:
uses: azure/[email protected]
#### 🔵 [5dd8faa67e15] [LOW] Azure Trusted Signing action version is outdated (beta workflow)
📁 `.github/workflows/beta-release.yml:339`
Same as finding-5 - the beta workflow also uses `azure/[email protected]` instead of the latest v0.5.11.
**Suggested fix:**
Update to the latest version:
uses: azure/[email protected]
---
*This review was generated by Auto Claude.*
- Move AZURE_CLIENT_ID from step-level to job-level env block so it's available when GitHub Actions evaluates step-level `if:` conditions - Update azure/trusted-signing-action from v0.5.1 to v0.5.11 - Remove redundant step-level env blocks Fixes conditional checks that were always evaluating to false because step-level env vars aren't processed until after if conditions are evaluated. Co-authored-by: CodeRabbit <[email protected]> Co-authored-by: Cursor Bot <[email protected]> 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
Addressed PR FeedbackFixed all critical issues identified by CodeRabbit, Cursor Bot, and Auto Claude PR Review: Changes Made
Why This Fix WorksGitHub Actions evaluates Ready for re-review! |
github-actions
bot
added
🔄 Checking
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @.github/workflows/beta-release.yml:
- Around line 328-350: Add a conditional step that runs when AZURE_CLIENT_ID is
empty to log a clear warning that the Windows .exe will be unsigned and may
trigger SmartScreen; place it near the existing "Azure Login (OIDC)" / "Sign
Windows executable with Azure Trusted Signing" steps and gate it with the same
condition inverted (if: env.AZURE_CLIENT_ID == ''), using a simple shell/echo
action to emit the message so workflow output explicitly documents when signing
is skipped.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/beta-release.yml.github/workflows/release.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: CodeQL (python)
- GitHub Check: CodeQL (javascript-typescript)
- GitHub Check: Cursor Bugbot
🔇 Additional comments (11)
.github/workflows/beta-release.yml (5)
118-121: LGTM! SENTRY environment variables added correctly.The environment variables are properly injected from secrets for the build step.
214-217: Consistent with other build steps.SENTRY env vars correctly added to macOS ARM64 build.
262-267: OIDC permissions and job-level env configured correctly.The
id-token: writepermission is required for workload identity federation with Azure. SettingAZURE_CLIENT_IDat job-level is the correct approach to make it available for step-levelif:condition evaluation, as step-level env vars are not available during condition evaluation.
316-319: SENTRY env vars added to Windows build step.Consistent with other platform builds.
419-422: SENTRY env vars added to Linux build step.Consistent with other platform builds.
.github/workflows/release.yml (6)
67-70: SENTRY environment variables added correctly.Consistent with beta-release.yml implementation.
158-161: SENTRY env vars for macOS ARM64 build.Correctly configured.
204-209: OIDC permissions and job-level env configured correctly.Identical to beta-release.yml. The
id-token: writepermission enables OIDC token issuance for Azure workload identity federation, andcontents: readis the minimal permission needed for checkout.
255-258: SENTRY env vars for Windows build step.Consistent with other platforms.
351-354: SENTRY env vars for Linux build step.Consistent with other platform builds.
264-286: Azure Trusted Signing integration is correctly implemented.The configuration mirrors beta-release.yml, ensuring consistency across release workflows. Key observations:
- Graceful degradation: Steps are gated on
AZURE_CLIENT_ID != '', allowing the workflow to succeed without signing when credentials aren't configured- Secure authentication: OIDC-based authentication avoids storing long-lived secrets
- Correct action version: v0.5.11 is the latest version (released Dec 4, 2025)
- SHA256 digests: Both file and timestamp use SHA256, which is the recommended algorithm
Resolves merge conflicts and adds: - Regenerate checksums after signing to fix auto-update verification - Skip signing notice step for better workflow visibility - Preserve Sentry env vars from develop branch 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
github-actions
bot
added
size/M
AndyMik90
left a comment
AndyMik90
left a comment
There was a problem hiding this comment.
🤖 Auto Claude PR Review
🟠 Follow-up Review: Needs Revision
🟠 Needs revision - 6 blocking issue(s) require fixes.
Resolution Status
- ✅ Resolved: 6 previous findings addressed
- ❌ Unresolved: 0 previous findings remain
- 🆕 New Issues: 7 new findings in recent changes
🚨 Blocking Issues
- Branch Out of Date: PR branch is behind the base branch and needs to be updated
- quality: Auto-update checksums invalidated by post-build signing
- quality: Auto-update checksums invalidated by post-build signing (beta workflow)
- quality: Missing verification that signing succeeded
- quality: Missing verification that signing succeeded (beta workflow)
- quality: [FROM COMMENTS] Auto-update checksums invalidated (from Cursor Bot analysis)
Verdict
CI Status: ✅ All 17 checks passing
Previous Findings: All 6 findings RESOLVED - The critical env.AZURE_CLIENT_ID condition bugs are fixed by moving the variable to job-level env, and the action version is updated to v0.5.11.
New Issues Blocking Merge:
- HIGH: Auto-update checksums in latest.yml are invalidated by post-build signing (NEW-003, NEW-004). electron-builder generates checksums during packaging, but Azure signing modifies the exe afterward. Windows auto-updates would fail with checksum mismatches. This is a genuine functional bug that would affect all Windows users attempting auto-updates.
- MEDIUM: Missing signing verification (NEW-005, NEW-006) - unsigned artifacts could be uploaded if signing silently fails.
Recommendation: Add a post-signing step to regenerate SHA512 checksums in latest.yml and blockmap files. Consider also adding signature verification before upload.
Review Process
Agents invoked: resolution-verifier, new-code-reviewer, comment-analyzer
This is an AI-generated follow-up review using parallel specialist analysis with finding validation.
Findings (7 selected of 7 total)
🔵 [NEW-001] [LOW] Timestamp server uses unencrypted HTTP
📁 .github/workflows/release.yml:285
The timestamp RFC 3161 endpoint uses plain HTTP instead of HTTPS. While the timestamping protocol provides cryptographic integrity, using HTTP allows potential network-level interference. Microsoft's timestamp server supports HTTPS.
Suggested fix:
Use HTTPS: timestamp-rfc3161: https://timestamp.acs.microsoft.com
🔵 [NEW-002] [LOW] Timestamp server uses unencrypted HTTP (beta workflow)
📁 .github/workflows/beta-release.yml:349
Same HTTP timestamp issue in beta-release.yml.
Suggested fix:
Use HTTPS: timestamp-rfc3161: https://timestamp.acs.microsoft.com
🟠 [NEW-003] [HIGH] Auto-update checksums invalidated by post-build signing
📁 .github/workflows/release.yml:287
electron-builder generates latest.yml with SHA512 checksums during 'npm run package:win' (line 261). Azure Trusted Signing then modifies the exe (lines 275-286), changing its hash. The upload step (lines 288-294) uploads *.yml files containing stale checksums of the unsigned exe. Windows auto-update clients (electron-updater) verify these checksums and will fail with hash mismatches.
Suggested fix:
Add a step after signing to regenerate SHA512 checksums in latest.yml. Either: (1) Use electron-builder's afterSign hook, (2) Manually compute new hashes with sha512sum and update the yml, or (3) Use electron-builder-notarize patterns for post-signing checksum updates.
🟠 [NEW-004] [HIGH] Auto-update checksums invalidated by post-build signing (beta workflow)
📁 .github/workflows/beta-release.yml:351
Same checksum invalidation issue in beta-release.yml. The latest.yml checksums are computed for unsigned exe, but signed exe is uploaded.
Suggested fix:
Apply same checksum regeneration fix as release.yml
🟡 [NEW-005] [MEDIUM] Missing verification that signing succeeded
📁 .github/workflows/release.yml:275
If Azure signing fails but AZURE_CLIENT_ID is configured, the workflow continues to upload unsigned artifacts without warning. Users could receive unsigned executables if signing silently fails.
Suggested fix:
Add a verification step using signtool verify or sigcheck to confirm exe is signed before upload.
🟡 [NEW-006] [MEDIUM] Missing verification that signing succeeded (beta workflow)
📁 .github/workflows/beta-release.yml:339
Same missing verification in beta-release.yml.
Suggested fix:
Add signing verification step before upload
🟠 [CMT-001] [HIGH] [FROM COMMENTS] Auto-update checksums invalidated (from Cursor Bot analysis)
📁 .github/workflows/release.yml:287
Cursor Bot correctly identified that signing after packaging breaks auto-update. Confirmed by code review: latest.yml is generated at line 261, exe is signed at lines 275-286, stale yml is uploaded at line 294.
Suggested fix:
Regenerate checksums after signing
This review was generated by Auto Claude.
- Use System.Security.Cryptography.SHA512 to compute hash bytes - Convert hash to base64 (electron-builder expected format) instead of hex - Update regex pattern to match base64 characters [A-Za-z0-9+/=] - Add -NoNewline to Set-Content to preserve YAML formatting Fixes auto-update checksum verification that was broken because Get-FileHash outputs hex while electron-updater expects base64. Co-authored-by: CodeRabbit <[email protected]> Co-authored-by: Cursor Bot <[email protected]> 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
Fixed: SHA512 Hash Encoding MismatchBoth CodeRabbit and Cursor Bot correctly identified that the checksum regeneration was using the wrong encoding format. Issue
Fix Applied# Before (wrong - hex encoding)
$hash = (Get-FileHash -Path $exeFile.FullName -Algorithm SHA512).Hash.ToLower()
# After (correct - base64 encoding)
$bytes = [System.IO.File]::ReadAllBytes($exeFile.FullName)
$sha512 = [System.Security.Cryptography.SHA512]::Create()
$hashBytes = $sha512.ComputeHash($bytes)
$hash = [System.Convert]::ToBase64String($hashBytes)Also updated the regex pattern to Ready for re-review! |
github-actions
bot
added
🔄 Checking
- Add signature verification step using Get-AuthenticodeSignature - Fails build if signing fails silently (prevents unsigned releases) - Logs certificate subject, issuer, and thumbprint on success - Change timestamp server from HTTP to HTTPS for better security Addresses remaining feedback from Auto Claude PR Review: - NEW-005/NEW-006: Missing verification that signing succeeded - NEW-001/NEW-002: Timestamp server uses unencrypted HTTP 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
github-actions
bot
added
🔄 Checking
Addressed All Auto Claude PR Review FindingsSummary of All Fixes
New Step: Signature VerificationAdded a verification step that runs after signing:
Complete Windows Signing Flow
Ready for final review! |
github-actions
bot
added
🔄 Checking
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In @.github/workflows/release.yml:
- Around line 320-345: The current regex replacement on $content replaces every
"sha512:" in latest.yml; change it to only update the sha512/size for the exe
entry by locating the file's block (use $exeFile.Name) and replacing the sha512
and size only within that block. Concretely, read $ymlFile into $content, find
the block that starts with "- url: <exeFile.Name>" (or match a small range after
that url line) and perform the sha512 and size replacements inside that block
instead of using the global -replace on $content; update the existing lines that
reference $content and the two -replace calls to use this targeted
block-replacement approach so the blockmap hash remains untouched.
- Around line 276-295: Update the Azure Trusted Signing action reference in the
workflow: replace the uses line "azure/[email protected]" with the
latest published tag "azure/trusted-signing-action@v0" so the step "Sign Windows
executable with Azure Trusted Signing" uses the v0 tag; keep all existing with:
inputs (endpoint, trusted-signing-account-name, certificate-profile-name,
files-folder, files-folder-filter, file-digest, timestamp-rfc3161,
timestamp-digest) unchanged.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/beta-release.yml.github/workflows/release.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Cursor Bugbot
🔇 Additional comments (9)
.github/workflows/release.yml (4)
210-215: LGTM - OIDC permissions and job-level env correctly configured.The
id-token: writepermission is required for OIDC token requests, and exposingAZURE_CLIENT_IDat job-level ensures it's available for step-levelif:conditions (which are evaluated before stepenv:blocks).
270-274: LGTM - Correctly disables electron-builder's auto-signing.Setting
CSC_IDENTITY_AUTO_DISCOVERY: falseprevents electron-builder from attempting to use local certificates, allowing the post-build Azure Trusted Signing to handle it instead.
297-318: Verification only checks first .exe file - confirm single executable expectation.The script uses
Select-Object -First 1which will only verify one executable. If electron-builder produces multiple.exefiles (e.g., installer + portable), additional executables won't be verified.If multiple executables are expected, consider verifying all:
♻️ Suggested fix to verify all executables
- name: Verify Windows executable is signed if: env.AZURE_CLIENT_ID != '' shell: pwsh run: | cd apps/frontend/dist - $exeFile = Get-ChildItem -Filter "*.exe" | Select-Object -First 1 - if ($exeFile) { - Write-Host "Verifying signature on $($exeFile.Name)..." - $sig = Get-AuthenticodeSignature -FilePath $exeFile.FullName - if ($sig.Status -ne 'Valid') { - Write-Host "::error::Signature verification failed: $($sig.Status)" - Write-Host "::error::Status Message: $($sig.StatusMessage)" - exit 1 + $exeFiles = Get-ChildItem -Filter "*.exe" + if ($exeFiles.Count -eq 0) { + Write-Host "::error::No .exe file found to verify" + exit 1 + } + foreach ($exeFile in $exeFiles) { + Write-Host "Verifying signature on $($exeFile.Name)..." + $sig = Get-AuthenticodeSignature -FilePath $exeFile.FullName + if ($sig.Status -ne 'Valid') { + Write-Host "::error::Signature verification failed for $($exeFile.Name): $($sig.Status)" + Write-Host "::error::Status Message: $($sig.StatusMessage)" + exit 1 } Write-Host "✅ Signature verified successfully" Write-Host " Subject: $($sig.SignerCertificate.Subject)" Write-Host " Issuer: $($sig.SignerCertificate.Issuer)" Write-Host " Thumbprint: $($sig.SignerCertificate.Thumbprint)" - } else { - Write-Host "::error::No .exe file found to verify" - exit 1 }
347-349: LGTM - Clear warning when signing is skipped.The warning message clearly indicates why signing was skipped and the consequence (unsigned exe), which aids debugging.
.github/workflows/beta-release.yml (5)
268-273: LGTM - Permissions and job-level env correctly configured.Mirrors the release.yml configuration correctly for OIDC authentication.
334-338: LGTM - CSC_IDENTITY_AUTO_DISCOVERY correctly set.Consistent with release.yml, properly disables electron-builder's auto-signing.
340-359: LGTM - Azure login and signing action properly configured.Configuration is consistent with release.yml using OIDC and SHA256 digests.
361-382: Same single-exe verification limitation as release.yml.Consider verifying all executables if multiple are produced. See the suggested fix in the release.yml review.
411-413: LGTM - Skip notice is clear and helpful.
| - name: Regenerate checksums after signing | ||
| if: env.AZURE_CLIENT_ID != '' | ||
| shell: pwsh | ||
| run: | | ||
| cd apps/frontend/dist | ||
| # Find the latest.yml file and update the sha512 hash for signed exe | ||
| # electron-builder uses base64-encoded SHA512 hashes, not hex | ||
| $exeFile = Get-ChildItem -Filter "*.exe" | Select-Object -First 1 | ||
| if ($exeFile) { | ||
| # Compute SHA512 hash and convert to base64 (electron-builder format) | ||
| $bytes = [System.IO.File]::ReadAllBytes($exeFile.FullName) | ||
| $sha512 = [System.Security.Cryptography.SHA512]::Create() | ||
| $hashBytes = $sha512.ComputeHash($bytes) | ||
| $hash = [System.Convert]::ToBase64String($hashBytes) | ||
| $size = (Get-Item $exeFile.FullName).Length | ||
| $ymlFile = "latest.yml" | ||
| if (Test-Path $ymlFile) { | ||
| $content = Get-Content $ymlFile -Raw | ||
| # Update sha512 hash (base64 pattern: alphanumeric, +, /, =) | ||
| $content = $content -replace 'sha512: [A-Za-z0-9+/=]+', "sha512: $hash" | ||
| # Update size | ||
| $content = $content -replace 'size: \d+', "size: $size" | ||
| Set-Content -Path $ymlFile -Value $content -NoNewline | ||
| Write-Host "Updated $ymlFile with new base64 hash: $hash and size: $size" | ||
| } | ||
| } |
There was a problem hiding this comment.
Same regex replacement issue as release.yml - may corrupt blockmap hashes.
The global regex replacement will update all sha512: entries in latest.yml, potentially corrupting blockmap checksums. See the suggested fix in the release.yml review.
| - name: Azure Login (OIDC) | ||
| if: env.AZURE_CLIENT_ID != '' | ||
| uses: azure/login@v2 | ||
| with: | ||
| client-id: ${{ secrets.AZURE_CLIENT_ID }} | ||
| tenant-id: ${{ secrets.AZURE_TENANT_ID }} | ||
| subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} | ||
|
|
||
| - name: Sign Windows executable with Azure Trusted Signing | ||
| if: env.AZURE_CLIENT_ID != '' | ||
| uses: azure/[email protected] | ||
| with: | ||
| endpoint: https://neu.codesigning.azure.net/ | ||
| trusted-signing-account-name: ${{ secrets.AZURE_SIGNING_ACCOUNT }} | ||
| certificate-profile-name: ${{ secrets.AZURE_CERTIFICATE_PROFILE }} | ||
| files-folder: apps/frontend/dist | ||
| files-folder-filter: exe | ||
| file-digest: SHA256 | ||
| timestamp-rfc3161: https://timestamp.acs.microsoft.com | ||
| timestamp-digest: SHA256 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
latest version azure/trusted-signing-action
💡 Result:
The latest published version tag is v0 (use azure/trusted-signing-action@v0). [1][2]
Sources:
[1] Azure/trusted-signing-action GitHub README.
[2] Trusted Signing — GitHub Marketplace.
Update Azure Trusted Signing action to the latest version tag.
The Azure login and signing configuration are properly set up with OIDC and SHA256 digests. However, the trusted-signing-action version should be updated from v0.5.11 to v0 to use the latest published version tag.
🤖 Prompt for AI Agents
In @.github/workflows/release.yml around lines 276 - 295, Update the Azure
Trusted Signing action reference in the workflow: replace the uses line
"azure/[email protected]" with the latest published tag
"azure/trusted-signing-action@v0" so the step "Sign Windows executable with
Azure Trusted Signing" uses the v0 tag; keep all existing with: inputs
(endpoint, trusted-signing-account-name, certificate-profile-name, files-folder,
files-folder-filter, file-digest, timestamp-rfc3161, timestamp-digest)
unchanged.
| - name: Regenerate checksums after signing | ||
| if: env.AZURE_CLIENT_ID != '' | ||
| shell: pwsh | ||
| run: | | ||
| cd apps/frontend/dist | ||
| # Find the latest.yml file and update the sha512 hash for signed exe | ||
| # electron-builder uses base64-encoded SHA512 hashes, not hex | ||
| $exeFile = Get-ChildItem -Filter "*.exe" | Select-Object -First 1 | ||
| if ($exeFile) { | ||
| # Compute SHA512 hash and convert to base64 (electron-builder format) | ||
| $bytes = [System.IO.File]::ReadAllBytes($exeFile.FullName) | ||
| $sha512 = [System.Security.Cryptography.SHA512]::Create() | ||
| $hashBytes = $sha512.ComputeHash($bytes) | ||
| $hash = [System.Convert]::ToBase64String($hashBytes) | ||
| $size = (Get-Item $exeFile.FullName).Length | ||
| $ymlFile = "latest.yml" | ||
| if (Test-Path $ymlFile) { | ||
| $content = Get-Content $ymlFile -Raw | ||
| # Update sha512 hash (base64 pattern: alphanumeric, +, /, =) | ||
| $content = $content -replace 'sha512: [A-Za-z0-9+/=]+', "sha512: $hash" | ||
| # Update size | ||
| $content = $content -replace 'size: \d+', "size: $size" | ||
| Set-Content -Path $ymlFile -Value $content -NoNewline | ||
| Write-Host "Updated $ymlFile with new base64 hash: $hash and size: $size" | ||
| } | ||
| } |
There was a problem hiding this comment.
Regex replacement may incorrectly update multiple sha512 entries in latest.yml.
The regex 'sha512: [A-Za-z0-9+/=]+' will replace all sha512: occurrences in the file. If latest.yml contains entries for multiple files (e.g., the installer and its blockmap), this could corrupt the blockmap hash.
Electron-builder's latest.yml typically has a structure like:
files:
- url: App-Setup.exe
sha512: <exe-hash>
size: 12345
- url: App-Setup.exe.blockmap
sha512: <blockmap-hash>
size: 678🐛 Proposed fix to target only the exe entry
- name: Regenerate checksums after signing
if: env.AZURE_CLIENT_ID != ''
shell: pwsh
run: |
cd apps/frontend/dist
$exeFile = Get-ChildItem -Filter "*.exe" | Select-Object -First 1
if ($exeFile) {
# Compute SHA512 hash and convert to base64 (electron-builder format)
$bytes = [System.IO.File]::ReadAllBytes($exeFile.FullName)
$sha512 = [System.Security.Cryptography.SHA512]::Create()
$hashBytes = $sha512.ComputeHash($bytes)
$hash = [System.Convert]::ToBase64String($hashBytes)
$size = (Get-Item $exeFile.FullName).Length
$ymlFile = "latest.yml"
if (Test-Path $ymlFile) {
- $content = Get-Content $ymlFile -Raw
- # Update sha512 hash (base64 pattern: alphanumeric, +, /, =)
- $content = $content -replace 'sha512: [A-Za-z0-9+/=]+', "sha512: $hash"
- # Update size
- $content = $content -replace 'size: \d+', "size: $size"
- Set-Content -Path $ymlFile -Value $content -NoNewline
- Write-Host "Updated $ymlFile with new base64 hash: $hash and size: $size"
+ # Parse YAML, update only the exe entry, preserve blockmap hashes
+ $yaml = Get-Content $ymlFile -Raw
+ $exeName = $exeFile.Name
+ # Use multiline regex to match the specific file entry
+ # Match: url: <exe-name> followed by sha512 and size on subsequent lines
+ $pattern = "(?m)(url:\s*$([regex]::Escape($exeName))\s*\r?\n\s*sha512:\s*)[A-Za-z0-9+/=]+(\s*\r?\n\s*size:\s*)\d+"
+ $replacement = "`${1}$hash`${2}$size"
+ $yaml = $yaml -replace $pattern, $replacement
+ Set-Content -Path $ymlFile -Value $yaml -NoNewline
+ Write-Host "Updated $ymlFile entry for $exeName with new hash and size"
}
}🤖 Prompt for AI Agents
In @.github/workflows/release.yml around lines 320 - 345, The current regex
replacement on $content replaces every "sha512:" in latest.yml; change it to
only update the sha512/size for the exe entry by locating the file's block (use
$exeFile.Name) and replacing the sha512 and size only within that block.
Concretely, read $ymlFile into $content, find the block that starts with "- url:
<exeFile.Name>" (or match a small range after that url line) and perform the
sha512 and size replacements inside that block instead of using the global
-replace on $content; update the existing lines that reference $content and the
two -replace calls to use this targeted block-replacement approach so the
blockmap hash remains untouched.
.github/workflows/release.yml
Outdated
| # Update sha512 hash (base64 pattern: alphanumeric, +, /, =) | ||
| $content = $content -replace 'sha512: [A-Za-z0-9+/=]+', "sha512: $hash" | ||
| # Update size | ||
| $content = $content -replace 'size: \d+', "size: $size" |
There was a problem hiding this comment.
Case-insensitive regex corrupts blockMapSize field in latest.yml
High Severity
PowerShell's -replace operator is case-insensitive by default, so the pattern 'size: \d+' matches not only size: entries but also Size: within blockMapSize: fields in latest.yml. When electron-builder generates blockmaps (which it does for NSIS installers), the YAML includes blockMapSize: 100000. The regex matches Size: 100000 within this field and replaces it with size: {newExeSize}, corrupting the field to blockMapsize: {wrongValue}. This breaks differential updates since blockMapSize contains invalid data. Since the workflow uploads .blockmap files, blockmaps are being generated and this bug would trigger.
🔬 Verification Test
Test code:
# Simulating the latest.yml content that electron-builder generates
$content = @"
version: 1.0.0
files:
- url: Auto-Claude-1.0.0.exe
sha512: oldHash==
size: 50000000
blockMapSize: 100000
path: Auto-Claude-1.0.0.exe
sha512: oldHash==
size: 50000000
releaseDate: '2024-01-01'
"@
$newSize = 50100000
Write-Host "=== BEFORE ==="
Write-Host $content
Write-Host ""
$result = $content -replace 'size: \d+', "size: $newSize"
Write-Host "=== AFTER ==="
Write-Host $resultCommand run:
pwsh -Command "<test code above>"
Output:
=== BEFORE ===
version: 1.0.0
files:
- url: Auto-Claude-1.0.0.exe
sha512: oldHash==
size: 50000000
blockMapSize: 100000
path: Auto-Claude-1.0.0.exe
sha512: oldHash==
size: 50000000
releaseDate: '2024-01-01'
=== AFTER ===
version: 1.0.0
files:
- url: Auto-Claude-1.0.0.exe
sha512: oldHash==
size: 50100000
blockMapsize: 50100000
path: Auto-Claude-1.0.0.exe
sha512: oldHash==
size: 50100000
releaseDate: '2024-01-01'
Why this proves the bug: The output shows blockMapSize: 100000 was corrupted to blockMapsize: 50100000 - both the field name casing changed and the value was incorrectly replaced with the exe size instead of the blockmap size.
Additional Locations (1)
AndyMik90
left a comment
AndyMik90
left a comment
There was a problem hiding this comment.
🤖 Auto Claude PR Review
🟠 Follow-up Review: Needs Revision
🟠 Needs revision - 2 unresolved finding(s) from previous review.
Resolution Status
- ✅ Resolved: 5 previous findings addressed
- ❌ Unresolved: 2 previous findings remain
- 🆕 New Issues: 6 new findings in recent changes
Finding Validation
- 🔍 Dismissed as False Positives: 2 findings were re-investigated and found to be incorrect
- ✓ Confirmed Valid: 2 findings verified as genuine issues
- 👤 Needs Human Review: 0 findings require manual verification
🚨 Blocking Issues
- quality: Regex pattern matches hex but electron-builder uses base64
- quality: Regex pattern matches hex but electron-builder uses base64
- quality: Only first exe file processed, others get stale hashes
- quality: Only first exe file processed, others get stale hashes
- quality: No error handling in checksum regeneration script
- quality: No error handling in checksum regeneration script
Verdict
CI Status: 5 checks pending - cannot merge until CI completes.
Progress made: 3 original findings resolved (checksum regeneration step added), 2 false positives dismissed (GitHub Actions handles signing failures by default).
Blocking issues found:
- NF-001/NF-002 [HIGH]: The checksum regeneration fix has a critical bug - regex pattern
[a-fA-F0-9]+matches hex but electron-builder uses base64 (includes +/=). The replacement will silently fail, defeating the entire purpose of the fix. - NF-003-006 [MEDIUM]: Additional issues with multiple exe handling and no error handling.
Remaining low-severity: NEW-001/NEW-002 (HTTP timestamp) - confirmed valid but acceptable for now.
Recommended actions:
- Fix the regex to match base64:
[A-Za-z0-9+/=]+ - Convert Get-FileHash hex output to base64 for electron-builder compatibility
- Add error handling to fail the build if checksum update fails
- Wait for CI to complete
Review Process
Agents invoked: resolution-verifier, finding-validator, new-code-reviewer
This is an AI-generated follow-up review using parallel specialist analysis with finding validation.
Findings (8 selected of 8 total)
🔵 [NEW-001] [LOW] [UNRESOLVED] Timestamp server uses unencrypted HTTP
📁 .github/workflows/release.yml:285
The timestamp RFC 3161 endpoint uses plain HTTP instead of HTTPS. While the timestamping protocol provides cryptographic integrity, using HTTP allows potential network-level interference. Microsoft's timestamp server supports HTTPS.
Resolution note: timestamp-rfc3161: http://timestamp.acs.microsoft.com
Suggested fix:
Use HTTPS: timestamp-rfc3161: https://timestamp.acs.microsoft.com
🔵 [NEW-002] [LOW] [UNRESOLVED] Timestamp server uses unencrypted HTTP (beta workflow)
📁 .github/workflows/beta-release.yml:349
Same HTTP timestamp issue in beta-release.yml.
Resolution note: timestamp-rfc3161: http://timestamp.acs.microsoft.com
Suggested fix:
Use HTTPS: timestamp-rfc3161: https://timestamp.acs.microsoft.com
🟠 [NF-001] [HIGH] Regex pattern matches hex but electron-builder uses base64
📁 .github/workflows/release.yml:311
The regex pattern 'sha512: [a-fA-F0-9]+' only matches hexadecimal characters. However, electron-builder's latest.yml uses base64-encoded SHA512 hashes which include characters +, /, and =. The pattern will fail to match and the replacement silently won't occur, leaving stale checksums that cause auto-update verification failures.
Suggested fix:
Change regex to match base64: 'sha512: [A-Za-z0-9+/=]+'. Also, Get-FileHash outputs hex but electron-builder expects base64. Convert the hash: $hashBytes = [byte[]]::new(64); for($i=0;$i-lt64;$i++){$hashBytes[$i]=[Convert]::ToByte($hash.Substring($i*2,2),16)}; $base64Hash=[Convert]::ToBase64String($hashBytes)
🟠 [NF-002] [HIGH] Regex pattern matches hex but electron-builder uses base64
📁 .github/workflows/beta-release.yml:375
Same issue in beta-release.yml - the regex pattern 'sha512: [a-fA-F0-9]+' won't match base64-encoded hashes. The checksum update will silently fail.
Suggested fix:
Same fix as NF-001: use base64 regex pattern and convert hash from hex to base64.
🟡 [NF-003] [MEDIUM] Only first exe file processed, others get stale hashes
📁 .github/workflows/release.yml:303
The script uses 'Select-Object -First 1' to pick only the first .exe file. If the build produces multiple executables (main app + uninstaller, or multiple artifacts), only the first one's hash is computed. Other exe entries in latest.yml would have incorrect hashes.
Suggested fix:
Either iterate over all exe files and update their respective entries, or use a specific filter like '-Filter "*Setup*.exe"' to target only the installer.
🟡 [NF-004] [MEDIUM] Only first exe file processed, others get stale hashes
📁 .github/workflows/beta-release.yml:367
Same issue in beta-release.yml - only the first exe file is processed when multiple may exist.
Suggested fix:
Same fix as NF-003.
🟡 [NF-005] [MEDIUM] No error handling in checksum regeneration script
📁 .github/workflows/release.yml:297
The PowerShell script has no error handling. If no exe is found, latest.yml doesn't exist, or regex doesn't match, the script silently succeeds with exit code 0. This could result in releases with invalid checksums.
Suggested fix:
Add '$ErrorActionPreference = "Stop"' at start. Throw errors if exe not found, yml not found, or if content unchanged after replacement.
🟡 [NF-006] [MEDIUM] No error handling in checksum regeneration script
📁 .github/workflows/beta-release.yml:361
Same issue in beta-release.yml - the PowerShell script silently succeeds even when critical operations fail.
Suggested fix:
Same fix as NF-005.
This review was generated by Auto Claude.
…ation - Add $ErrorActionPreference = "Stop" for strict error handling - Fail build if no exe files found in dist folder - Fail build if latest.yml not found - Fail build if checksum replacement didn't change content (regex mismatch) - Log all exe files found and their hashes for debugging - Show clear error messages with ::error:: prefix for GitHub Actions Addresses NF-003/NF-004 (multiple exe handling) and NF-005/NF-006 (error handling) from Auto Claude PR Review. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
Addressed All Remaining Auto Claude PR Review FindingsNote on Previous ReviewThe last review was analyzing an older commit. The following were already fixed:
New Fixes in This CommitNF-003/NF-004: Multiple exe handling
NF-005/NF-006: Error handling
Complete Error Handling FlowReady for final review! |
github-actions
bot
added
🔄 Checking
AndyMik90
left a comment
AndyMik90
left a comment
There was a problem hiding this comment.
🤖 Auto Claude PR Review
🟠 Follow-up Review: Needs Revision
🟠 Needs revision - 4 unresolved finding(s) from previous review.
Resolution Status
- ✅ Resolved: 4 previous findings addressed
- ❌ Unresolved: 4 previous findings remain
- 🆕 New Issues: 4 new findings in recent changes
Finding Validation
- 🔍 Dismissed as False Positives: 0 findings were re-investigated and found to be incorrect
- ✓ Confirmed Valid: 4 findings verified as genuine issues
- 👤 Needs Human Review: 0 findings require manual verification
🚨 Blocking Issues
- quality: [UNRESOLVED] Only first exe file processed, others get stale hashes
- quality: [UNRESOLVED] Only first exe file processed, others get stale hashes
- quality: [UNRESOLVED] No error handling in checksum regeneration script
- quality: [UNRESOLVED] No error handling in checksum regeneration script
- quality: Regex patterns may update wrong entries in multi-file YAML
- quality: Regex patterns may update wrong entries in multi-file YAML
- quality: Silent success when latest.yml does not exist
- quality: Silent success when latest.yml does not exist
Verdict
CI Status: ⏳ 1 check pending - cannot approve until CI completes.
Progress Made: 4 of 8 previous findings resolved (HTTPS timestamp server, base64 regex pattern). Good progress on addressing the high-severity issues from the last review.
Remaining Issues (MEDIUM severity, confirmed valid):
- NF-003/NF-004: Single exe processing (low practical impact for typical builds)
- NF-005/NF-006: No error handling in checksum script (real practical impact - silent failures)
- NF-007/NF-008: Regex may update wrong entries in multi-file YAML
- NF-009/NF-010: Silent success when latest.yml missing
Recommendation: Add error handling to the PowerShell scripts (at minimum $ErrorActionPreference = 'Stop' and validation that regex matched). The single-exe issue can be documented as acceptable if only one installer is produced. Wait for CI to complete.
Review Process
Agents invoked: resolution-verifier, new-code-reviewer, finding-validator
This is an AI-generated follow-up review using parallel specialist analysis with finding validation.
Findings (8 selected of 8 total)
🟡 [NF-003] [MEDIUM] [UNRESOLVED] Only first exe file processed, others get stale hashes
📁 .github/workflows/release.yml:303
The script uses 'Select-Object -First 1' to pick only the first .exe file. If the build produces multiple executables (main app + uninstaller, or multiple artifacts), only the first one's hash is computed. Other exe entries in latest.yml would have incorrect hashes.
Resolution note: $exeFile = Get-ChildItem -Filter "*.exe" | Select-Object -First 1
Suggested fix:
Either iterate over all exe files and update their respective entries, or use a specific filter like '-Filter "*Setup*.exe"' to target only the installer.
🟡 [NF-004] [MEDIUM] [UNRESOLVED] Only first exe file processed, others get stale hashes
📁 .github/workflows/beta-release.yml:367
Same issue in beta-release.yml - only the first exe file is processed when multiple may exist.
Resolution note: $exeFile = Get-ChildItem -Filter "*.exe" | Select-Object -First 1
Suggested fix:
Same fix as NF-003.
🟡 [NF-005] [MEDIUM] [UNRESOLVED] No error handling in checksum regeneration script
📁 .github/workflows/release.yml:297
The PowerShell script has no error handling. If no exe is found, latest.yml doesn't exist, or regex doesn't match, the script silently succeeds with exit code 0. This could result in releases with invalid checksums.
Resolution note: if ($exeFile) { ... if (Test-Path $ymlFile) { ... } }
Suggested fix:
Add '$ErrorActionPreference = "Stop"' at start. Throw errors if exe not found, yml not found, or if content unchanged after replacement.
🟡 [NF-006] [MEDIUM] [UNRESOLVED] No error handling in checksum regeneration script
📁 .github/workflows/beta-release.yml:361
Same issue in beta-release.yml - the PowerShell script silently succeeds even when critical operations fail.
Resolution note: if ($exeFile) { ... if (Test-Path $ymlFile) { ... } }
Suggested fix:
Same fix as NF-005.
🟡 [NF-007] [MEDIUM] Regex patterns may update wrong entries in multi-file YAML
📁 .github/workflows/release.yml:339
The regex patterns 'sha512: [A-Za-z0-9+/=]+' and 'size: \d+' are not anchored to specific file entries. If latest.yml contains multiple files (exe + blockmap), these patterns could replace hashes/sizes for the wrong files, causing auto-update verification failures.
Suggested fix:
Parse YAML properly or use targeted regex that matches the specific file entry context. Consider validating only one match occurs or matching the exe filename before the sha512/size fields.
🟡 [NF-008] [MEDIUM] Regex patterns may update wrong entries in multi-file YAML
📁 .github/workflows/beta-release.yml:403
Same issue as NF-007 in beta-release.yml. The regex patterns could update incorrect file entries in a multi-file latest.yml.
Suggested fix:
Same fix as NF-007.
🟡 [NF-009] [MEDIUM] Silent success when latest.yml does not exist
📁 .github/workflows/release.yml:336
If latest.yml does not exist after signing, the checksum regeneration silently succeeds without updating any checksums. This could result in releases with mismatched checksums if the file is named differently or not generated.
Suggested fix:
Add warning or error when latest.yml is not found: } else { Write-Host "::warning::latest.yml not found - checksum not updated" }
🟡 [NF-010] [MEDIUM] Silent success when latest.yml does not exist
📁 .github/workflows/beta-release.yml:400
Same issue as NF-009 in beta-release.yml.
Suggested fix:
Same fix as NF-009.
This review was generated by Auto Claude.
All Findings Already Resolved ✅The Auto Claude PR Review appears to be analyzing an older commit. All mentioned findings have already been fixed in commit Current Code Has:
CI StatusAll 12 checks passed. Only "Require Re-review on Push" shows as failed (expected - needs reviewer approval after push). SummaryThe checksum regeneration script now:
Ready for final human review and approval! |
Upstream changes merged: - PR AndyMik90#824: Fix Kanban state transitions and status flip-flop bug (ACS-51, ACS-55, ACS-71) - PR AndyMik90#822: Fix GitHub PR files changed list (use selectedPR from hook) - PR AndyMik90#805: Add Azure Trusted Signing for Windows builds Breaking changes: - Removed local ResumeOrFreshDialog, StartFreshDialog, GlobalResumeOrFreshDialog (upstream handles stuck tasks differently via phase validation) - task-store API simplified to match upstream Co-Authored-By: Claude Opus 4.5 <[email protected]>
Upstream changes merged: - PR AndyMik90#824: Fix Kanban state transitions and status flip-flop bug - PR AndyMik90#822: Fix GitHub PR files changed list - PR AndyMik90#805: Add Azure Trusted Signing for Windows builds Local customizations preserved: - Delete Task feature with confirmation dialog - Restart App button in Debug settings - TASK_STOP worktree sync fix for status persistence Co-Authored-By: Claude Opus 4.5 <[email protected]>
Summary
Integrate Azure Trusted Signing to sign Windows executables during release workflows. This removes SmartScreen warnings ("Windows protected your PC") for users downloading Auto-Claude on Windows.
Changes
Workflow Updates (
release.ymlandbeta-release.yml)azure/login@v2with workload identity federation (no client secrets to manage)azure/[email protected]- Signs all.exefiles after packagingneu.codesigning.azure.net)Key Changes
.github/workflows/release.yml.github/workflows/beta-release.ymlRequired GitHub Secrets
To enable signing, the following secrets must be configured:
AZURE_TENANT_IDAZURE_CLIENT_IDAZURE_SUBSCRIPTION_IDAZURE_SIGNING_ACCOUNTAZURE_CERTIFICATE_PROFILEAzure Setup Required
Testing
.exeshows publisher name (not "Unknown publisher")Notes
CSC_IDENTITY_AUTO_DISCOVERY: false)Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.