Skip to content

Keep the display-helper signing keychain on the search list #457

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
theogravity merged 1 commit into from
Oct 26, 2026
Merged

Keep the display-helper signing keychain on the search list #457

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 28 additions & 16 deletions .github/workflows/release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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"
Expand All @@ -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"
;;
Expand Down Expand Up @@ -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"
Expand All @@ -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"
;;
Expand Down
14 changes: 9 additions & 5 deletions docs/release-and-ci.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
Loading