Skip to content

fix(ci): put the helper signing keychain ON the search list #458

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

fix(ci): put the helper signing keychain ON the search list #458

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
56 changes: 28 additions & 28 deletions .github/workflows/release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -897,30 +897,30 @@ 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. 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.
# cdhash. Build a second keychain for exactly that one call and
# make it the SOLE entry of the user's search list, the same way
# the CLI shards provision theirs above: codesign resolves a
# named identity through the search list, not the --keychain
# argument (probe run 40325026239 on this image: the same
# keychain failed "item could not be found" while unlisted and
# signed cleanly once listed). Login stays off the list exactly
# as on the CLI path. When Tauri's bundle-time keychain takes the
# list over later, both hold the SAME identity from the SAME p12,
# so the tauri#11992 trap - DIFFERENT identities in one view -
# cannot bite. The trap restores the baseline at step end.
KC="$CI_TMP/helper-sign.keychain-db"
KCPW="$(/usr/bin/openssl rand -hex 16)"
security create-keychain -p "$KCPW" "$KC"
security list-keychains -d user -s "$KC"
security unlock-keychain -p "$KCPW" "$KC"
printf '%s' "$MACOS_CERT_P12_BASE64" | base64 -d > "$CI_TMP/cert.p12"
security import "$CI_TMP/cert.p12" -k "$KC" -P "$MACOS_CERT_PASSWORD" -T /usr/bin/codesign
rm -f "$CI_TMP/cert.p12"
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 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.
# The keychain is the search list for this step (listed above);
# 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 @@ -1561,30 +1561,30 @@ 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. 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.
# cdhash. Build a second keychain for exactly that one call and
# make it the SOLE entry of the user's search list, the same way
# the CLI shards provision theirs above: codesign resolves a
# named identity through the search list, not the --keychain
# argument (probe run 40325026239 on this image: the same
# keychain failed "item could not be found" while unlisted and
# signed cleanly once listed). Login stays off the list exactly
# as on the CLI path. When Tauri's bundle-time keychain takes the
# list over later, both hold the SAME identity from the SAME p12,
# so the tauri#11992 trap - DIFFERENT identities in one view -
# cannot bite. The trap restores the baseline at step end.
KC="$CI_TMP/helper-sign.keychain-db"
KCPW="$(/usr/bin/openssl rand -hex 16)"
security create-keychain -p "$KCPW" "$KC"
security list-keychains -d user -s "$KC"
security unlock-keychain -p "$KCPW" "$KC"
printf '%s' "$MACOS_CERT_P12_BASE64" | base64 -d > "$CI_TMP/cert.p12"
security import "$CI_TMP/cert.p12" -k "$KC" -P "$MACOS_CERT_PASSWORD" -T /usr/bin/codesign
rm -f "$CI_TMP/cert.p12"
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 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.
# The keychain is the search list for this step (listed above);
# 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
17 changes: 10 additions & 7 deletions docs/release-and-ci.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -765,13 +765,16 @@ the experimental probe.
That signing runs during `cargo build`, before Tauri builds its own throwaway
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.
shard then makes that keychain the sole entry of the user's search list, exactly
as the CLI darwin shards provision theirs: `codesign` resolves a named identity
through the search list, not the `--keychain` argument, and on this runner image
`security create-keychain` does not add the keychain to that list. Run
40306776766 failed with "item could not be found" for exactly that reason, and
probe run 40325026239 on the same image confirmed the split: the same keychain
refused the identity while unlisted and signed cleanly once listed. When Tauri's
bundle-time keychain takes the list over later it carries the same single
identity from the same p12, so the two views are never in conflict, 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