deps: keyring 3 -> keyring-core 1 + apple-native stores#141
Merged
Conversation
The v4 architecture, taken the recommended way: link keyring-core directly and install the store explicitly (core ships no default) -- the in-memory mock in test/debug builds (the hermetic, prompt-free dev contract, unchanged), the macOS legacy-keychain store or the iOS protected-data store in release, chosen once behind the existing Once. Other targets install nothing and surface as signed-out, which is what Linux CI compiles. Upgrade-in-place is proven, not assumed: a dual-major probe binary wrote a session with keyring 3 against the real macOS keychain and keyring 4's store read it back byte-for-byte (same generic-password class, same service/account attributes), and a v4 delete is visible to v3. iOS is source-verified equivalent: both versions drive security-framework generic passwords with the same attribute mapping.
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
1 participant
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.
The held major from #139, done as its own pass with the upgrade proof it needed.
Architecture -- the v4-recommended direct path:
keyring-core+ explicit store install (core ships no default). Test/debug builds keep the hermetic no-Keychain-prompt mock contract viakeyring_core::mock; release installs the macOS legacy-keychain store or the iOS protected-data store once behind the existingOnce. Other targets (Linux CI) compile with no store and surface as signed-out.Upgrade-in-place proven, not assumed -- a dual-major probe binary against the real macOS keychain: keyring 3 wrote a session, v4's store read it back byte-for-byte (same generic-password class + service/account attributes), and a v4 delete is visible to v3. Existing installs keep their sessions. iOS is source-verified equivalent (both versions drive security-framework generic passwords with the same attribute mapping; v4 adds protection options on write only).
Full
just checkgreen locally incl. the desktop keychain-restore test on the mock path.