From 68eb8d06581b82e8494fcd4e611668eb74f47815 Mon Sep 17 00:00:00 2001 From: Theo Gravity Date: Mon, 26 Oct 2026 04:26:44 -0700 Subject: [PATCH] fix(ci): keep the helper signing keychain on the search list #454 created and imported a dedicated keychain for the display helper's build-script signature, then took it back off the user's search list and relied on codesign's --keychain alone. The dispatch on that commit (run 40306776766) died with the same "The specified item could not be found in the keychain": codesign resolves a named identity through the search list, not the --keychain argument, so an unlisted keychain is invisible to the lookup. Leave the keychain where create-keychain put it for the build's lifetime; it carries the same single identity as Tauri's bundle-time keychain, so there is no ambiguity, and the step trap restores the baseline. Both duplicated build-job bodies edited identically; docs paragraph follows. --- .github/workflows/release.yml | 44 ++++++++++++++++++++++------------- docs/release-and-ci.md | 14 +++++++---- 2 files changed, 37 insertions(+), 21 deletions(-) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index c5c12ceec..435793bad 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -897,10 +897,17 @@ jobs: # which runs BEFORE Tauri's keychain exists (it arrives at bundle # time), and a release helper must carry the Developer ID, not an # ad-hoc signature, because the permission grant follows the - # cdhash. Build a second keychain for exactly that one call, then - # take it back OFF the user's search list: the build script names - # it explicitly through APPLE_SIGNING_KEYCHAIN (--keychain), so - # Tauri still sees one identity in the shared view, not two. + # cdhash. Build a second keychain for exactly that one call. The + # build script names it explicitly through + # APPLE_SIGNING_KEYCHAIN (--keychain), and it also stays on the + # user's search list, because that is where codesign resolves + # identities: measured on the 2026-10-26 dispatch (run + # 40306776766), a --keychain call pointed at an UNLISTED keychain + # still died with "The specified item could not be found in the + # keychain". When Tauri's bundle-time keychain joins the list + # later, both hold the SAME identity from the SAME p12, and the + # tauri#11992 trap is about DIFFERENT identities in one view: + # with identical material there is no wrong key to pick. KC="$CI_TMP/helper-sign.keychain-db" KCPW="$(/usr/bin/openssl rand -hex 16)" security create-keychain -p "$KCPW" "$KC" @@ -911,10 +918,9 @@ jobs: security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k "$KCPW" "$KC" >/dev/null 2>&1 security find-identity -v -p codesigning "$KC" | grep -q "Developer ID Application" \ || { echo "imported p12 yielded no valid Developer ID Application identity"; exit 1; } - # create-keychain appends to the search list; reset it to the - # baseline this step started from, so this keychain is visible - # only to the call that names it. - security list-keychains -d user -s "$HOME/Library/Keychains/login.keychain-db" + # create-keychain left this keychain on the search list; that is + # where codesign needs it, so nothing unlists it mid-build. The + # trap restores the baseline when the step ends. trap 'rm -rf "$CI_TMP"; security delete-keychain "$KC" 2>/dev/null || true; security list-keychains -d user -s "$HOME/Library/Keychains/login.keychain-db"' EXIT export APPLE_SIGNING_KEYCHAIN="$KC" ;; @@ -1555,10 +1561,17 @@ jobs: # which runs BEFORE Tauri's keychain exists (it arrives at bundle # time), and a release helper must carry the Developer ID, not an # ad-hoc signature, because the permission grant follows the - # cdhash. Build a second keychain for exactly that one call, then - # take it back OFF the user's search list: the build script names - # it explicitly through APPLE_SIGNING_KEYCHAIN (--keychain), so - # Tauri still sees one identity in the shared view, not two. + # cdhash. Build a second keychain for exactly that one call. The + # build script names it explicitly through + # APPLE_SIGNING_KEYCHAIN (--keychain), and it also stays on the + # user's search list, because that is where codesign resolves + # identities: measured on the 2026-10-26 dispatch (run + # 40306776766), a --keychain call pointed at an UNLISTED keychain + # still died with "The specified item could not be found in the + # keychain". When Tauri's bundle-time keychain joins the list + # later, both hold the SAME identity from the SAME p12, and the + # tauri#11992 trap is about DIFFERENT identities in one view: + # with identical material there is no wrong key to pick. KC="$CI_TMP/helper-sign.keychain-db" KCPW="$(/usr/bin/openssl rand -hex 16)" security create-keychain -p "$KCPW" "$KC" @@ -1569,10 +1582,9 @@ jobs: security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k "$KCPW" "$KC" >/dev/null 2>&1 security find-identity -v -p codesigning "$KC" | grep -q "Developer ID Application" \ || { echo "imported p12 yielded no valid Developer ID Application identity"; exit 1; } - # create-keychain appends to the search list; reset it to the - # baseline this step started from, so this keychain is visible - # only to the call that names it. - security list-keychains -d user -s "$HOME/Library/Keychains/login.keychain-db" + # create-keychain left this keychain on the search list; that is + # where codesign needs it, so nothing unlists it mid-build. The + # trap restores the baseline when the step ends. trap 'rm -rf "$CI_TMP"; security delete-keychain "$KC" 2>/dev/null || true; security list-keychains -d user -s "$HOME/Library/Keychains/login.keychain-db"' EXIT export APPLE_SIGNING_KEYCHAIN="$KC" ;; diff --git a/docs/release-and-ci.md b/docs/release-and-ci.md index afbe24dc8..4419bbdf7 100644 --- a/docs/release-and-ci.md +++ b/docs/release-and-ci.md @@ -763,11 +763,15 @@ is `dev.subshell.display-helper`, shared by both desktop apps and distinct from the experimental probe. That signing runs during `cargo build`, before Tauri builds its own throwaway -keychain at bundle time, so the desktop shards hand it a dedicated unlisted -keychain through `APPLE_SIGNING_KEYCHAIN`: it is created, imported, and then -taken back off the user's search list, which is what lets the build script name -it explicitly while Tauri stays the sole owner of the shared identity lookup -(tauri#11992). +keychain at bundle time, so the desktop shards build a dedicated keychain for it +and hand its path to the build script through `APPLE_SIGNING_KEYCHAIN`. The +keychain stays on the user's search list for the build: `codesign` resolves a +named identity through the search list, not the `--keychain` argument, so the +keychain has to be listed for the identity to be found (run 40306776766 failed +with "item could not be found" when it was created, imported, and then taken +back off the list). It carries the same single identity as Tauri's later bundle +keychain, so listing both is no ambiguity, and the step's trap restores the +baseline search list when it ends. The helper has its own `Info.plist` version, which must increase when its code changes. Both apps reuse the newest installed helper; neither may downgrade it