fix(release): gate release identity and platform trust

[seonghobae]

Advances #960 on the existing Distribution/Update owner. This PR owns two release-quality boundaries: exact version identity and fail-closed platform trust before a version-tag build can hand artifacts to immutable publication.

Exact current identity

• Protected target: develop@889d782e88b4df28dcbb4ae3cfd6d99ef85d9844.
• Branch: fix/trusted-release-version-identity-960.
• Exact current head: b0bfbd2333f8f0a8eb2f8058f74cf985331aaebe.
• The current head is a normal two-parent non-force descendant of prior semantic head d33bb96ec1794c02492fea3e8cd5e36280709eae and protected develop@889d782e88b4df28dcbb4ae3cfd6d99ef85d9844.
• The only intervening protected delta from the old base was apps/desktop/src-tauri/Cargo.lock; this branch does not own that file and adopts the protected blob exactly. Fresh comparison reports behind_by=0 and exactly the seven release-owned files listed below.
• Current-head checks/reviews must be re-fetched after every head movement. Predecessor evidence never transfers.

Version identity boundary

scripts/checks/verify_release_identity.py fails closed unless VERSION, root package.json, the Tauri bundle version, and an applicable v* tag identify the same release. The tag build workflow owns a release-identity prerequisite; all Windows/macOS build jobs and immutable publication depend on it.

Platform trust boundary

scripts/checks/verify_release_platform_trust.py and the existing packager distinguish unsigned validation artifacts from publishable release artifacts:

• Windows tag packaging requires Authenticode Valid on every emitted .exe/.msi and an exact approved publisher subject supplied as BANDSCOPE_WINDOWS_PUBLISHER_SUBJECT.
• macOS tag packaging requires strict codesign verification of the application bundle, the exact approved BANDSCOPE_APPLE_TEAM_ID, a valid stapled notarization ticket on the DMG, and successful Gatekeeper assessment.
• paths are passed as subprocess arguments; signer identifiers are bounded and compared exactly; symlink/non-regular outputs fail closed; verifier output is not reused as a command or filesystem authority.
• non-tag PR/develop builds remain unsigned build evidence only and are never represented as release evidence.

Current valid blocker: release authority is not provisioned

Current review correctly identified that the repository can verify platform trust but the tag jobs still have no organization-approved signing/notarization authority wired into the build. No repository source contains or should invent these identities or secrets.

Before this PR can become merge-ready as a usable tag-release path, the organization must provision and approve:

Windows

• exact approved Authenticode publisher certificate subject;
• the signing certificate/private key mechanism accessible to the Windows release runners, such as an encrypted PFX secret or an approved external signing service;
• the certificate password or external signer authorization where applicable;
• an approved timestamp authority URL.

The tag job must then import/use that certificate only for the release build, configure Tauri with the resulting certificate thumbprint plus SHA-256 and the approved timestamp URL, and retain the current exact-subject post-build verification before upload.

macOS

• exact approved Apple Team ID;
• Developer ID Application signing certificate/private key accessible only to the macOS release jobs;
• Apple notarization authority, preferably an App Store Connect API key with issuer ID, key ID, and private key, or another explicitly approved Apple notarization credential path.

The tag job must then provide Tauri's signing/notarization environment only to the release build and retain current codesign/Team-ID/stapler/Gatekeeper verification before upload.

The repository must not guess a certificate subject, Team ID, timestamp authority, Apple account, signing provider, PFX/P12/P8 material, or secret name/value as though it were organization truth. Until those external identities exist, tag publication is intentionally fail-closed rather than silently producing an unsigned release.

TDD / causal repair chain

• 764e06c26c55ca6cf8c771389c010e6b0476e95e: RED contract for platform trust and tag-publication ownership.
• 13da983984ab5fa1069acee31af02f5464cd2747: native Authenticode/codesign/Team-ID/stapler/Gatekeeper verifier.
• 8de728b680c2657a6fc5e6bffb54dfe3861a76b3: packager-owned tag trust verification before artifact upload.
• d33bb96ec1794c02492fea3e8cd5e36280709eae: workflow/order and Windows/macOS verifier regression coverage.
• b0bfbd2333f8f0a8eb2f8058f74cf985331aaebe: non-force protected-base restack; no release-owned semantic delta changed.

The initial test-only head and every predecessor/cancelled/superseded hosted run are historical only.

Scope boundary

This PR does not claim #960 complete. After real signer authority is provisioned and wired, #960 still requires signed updater manifests, signature-verified updater consumption, staged rollout, rollback/repair, integrated checksums/SBOM/provenance/signature publication, version identity parity in shipped UI, and one exact integrated protected-head release receipt.

Current develop...HEAD semantic delta is seven files only: .github/workflows/build-baseline.yml, scripts/checks/verify_release_identity.py, scripts/checks/verify_release_platform_trust.py, scripts/harness/quickcheck.sh, scripts/release/package_desktop_artifact.py, and the two release trust/version regression suites.

Merge gate

Keep Draft and unmerged while release credentials/identities are unprovisioned, while any valid signing-wiring review finding remains unresolved, or while current-head evidence is incomplete. A qualifying exact head must have every applicable protected required check terminal-success, zero valid unresolved current-head findings, a qualifying independent non-author last-push approval, and ordinary protected-branch acceptance. Never self-approve, bypass protection, weaken a gate, or fabricate release evidence.

[coderabbitai]

📝 Walkthrough

Walkthrough

릴리스 정체성 검증 스크립트를 추가했습니다. VERSION, package.json, tauri.conf.json, 릴리스 태그의 일치를 확인합니다. 검증 작업을 빌드와 게시 작업의 선행 조건으로 연결하고, quickcheck 및 테스트에 검증 단계를 추가했습니다.

Changes

릴리스 정체성 검증

Layer / File(s)	Summary
릴리스 정체성 검증기 scripts/checks/verify_release_identity.py	VERSION을 기준으로 JSON 버전과 선택적 릴리스 태그를 검증합니다. 오류 발생 시 실패 코드를 반환합니다.
빌드 및 게시 게이트 연결 .github/workflows/build-baseline.yml, scripts/harness/quickcheck.sh	release-identity 작업을 추가했습니다. Windows 및 macOS 빌드와 immutable release 게시 작업이 검증 완료 후 실행되도록 설정했습니다. quickcheck에도 검증 명령을 추가했습니다.
검증 테스트 및 픽스처 services/analysis-engine/tests/test_release_version_identity.py	정상 버전, 메타데이터 불일치, 잘못된 태그, 다중 줄 VERSION, 워크플로 의존성을 검증합니다.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Merge Risk: ⚪ Minimal · up to b0d5e

The release guard now stops builds and publication when version metadata or the release tag disagrees. No actionable merge-blocking risk remains after normal checks and review.

Sequence Diagram(s)

sequenceDiagram
  participant ReleaseIdentityJob
  participant VerifyReleaseIdentity
  participant ReleaseMetadata
  participant BuildAndPublish
  ReleaseIdentityJob->>VerifyReleaseIdentity: verify_release_identity.py 실행
  VerifyReleaseIdentity->>ReleaseMetadata: VERSION 및 JSON 버전 읽기
  ReleaseMetadata-->>VerifyReleaseIdentity: 버전 메타데이터 반환
  VerifyReleaseIdentity-->>ReleaseIdentityJob: 검증 결과 반환
  ReleaseIdentityJob->>BuildAndPublish: 검증 성공 후 빌드 및 게시 허용

Loading

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 13 functions across 3 files. (1 skipped: 1…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	제목은 릴리스 식별자 검증 게이트와 플랫폼 신뢰성 강화를 설명합니다. 변경 사항의 주요 목적과 직접 관련됩니다.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/trusted-release-version-identity-960

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[devin-ai-integration]

Devin Review found 2 new potential issues.

[devin-ai-integration]

🔴 Tagged releases cannot produce artifacts

Tag builds pass an empty BANDSCOPE_WINDOWS_PUBLISHER_SUBJECT into verify_tag_platform_trust; no workflow job defines either required signer identity. Every platform packager fails before upload, so publication never runs.

Prompt for agents

The tag-triggered jobs in .github/workflows/build-baseline.yml invoke package_desktop_artifact.py without defining BANDSCOPE_WINDOWS_PUBLISHER_SUBJECT or BANDSCOPE_APPLE_TEAM_ID. They also contain no signing or notarization setup, so the newly mandatory platform trust verifier rejects every tagged build before artifact upload. Add the required release configuration and platform signing/notarization flow to the owning build jobs, expose the expected identities explicitly, and add workflow-level tests proving real tag jobs receive these values. Keep pull-request and branch builds unsigned if intended, while ensuring tagged builds can create verifiable artifacts.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[seonghobae]

Validated on current implementation head d33bb96ec1794c02492fea3e8cd5e36280709eae: this remains a real blocker. The verifier is correctly fail-closed, but the tag jobs do not yet possess an organization-approved Windows signing identity/certificate/timestamp authority or Apple Team ID/Developer ID/notarization authority. The PR title/body now state this explicitly and the thread remains unresolved; no signer identity, secret, timestamp service, or Apple authority will be fabricated in repository source. Once those external authorities are provisioned, the existing #960 owner must wire them into tag-only build steps and prove signed/notarized artifacts before upload.

[seonghobae]

Revalidated after the non-force protected-base restack. Exact current head is b0bfbd2333f8f0a8eb2f8058f74cf985331aaebe, with develop@889d782e88b4df28dcbb4ae3cfd6d99ef85d9844 as an ancestor and behind_by=0; the seven release-owned files are unchanged. This finding remains valid for the same external prerequisite: no repository-owned source can supply an approved Windows publisher/certificate/timestamp authority or Apple Team ID/Developer ID/notarization credential. The PR is Draft and this thread stays unresolved. No predecessor-head check/review receipt transfers.