Repository navigation
fix(desktop): keep the app's Keychain access across updates on macOS - #3437
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
macOS treats each ad-hoc app build as a new program, so Keychain asks again for paired-machine credentials after updates. When the user has created the local signing certificate, the updater now signs a separate copy of the verified download before installing and relaunching: bundled engine, desktop executable, then app bundle, followed by strict verification. A missing certificate or any failure logs the reason and installs the untouched ad-hoc download.
The custom updater already has a staging hook, so signing happens before relaunch rather than at the next startup. CLI and app share the codesign argument builder. Refresh the stale desktop lockfile entry for the local client crate so CI can use
--locked. Certificate creation remains an explicit one-time script step, per the requested scope; no certificate is created automatically.Changelog
Keep macOS Keychain access across app updates when the local signing certificate is configured.
Testing
Desktop clippy (
--locked --all-targets -- -D warnings), desktop and workspace formatting, and 34 updater unit tests pass (one pre-existing network test ignored). Workspacecargo check --workspace --testsalso passes. The identical shared-signing test is exercised by the desktop updater test run. Pure unit tests cover signing arguments, nested signing order, and skipping without an ad-hoc signature or certificate. No real Keychain items or signing identities were modified. Two consecutive live app updates remain a manual verification step.Closes #3435