Fix: attach kSecPrivateKeyAttrs (is_permanent, access control) on iOS and other non-macOS targets - #255
Open
AdrianEddy wants to merge 1 commit into
Open
Conversation
…S targets GenerateKeyOptions::to_dictionary builds the kSecPrivateKeyAttrs sub-dictionary (kSecAttrIsPermanent + kSecAttrAccessControl) on every target, but since kornelski#221 only attaches it under #[cfg(target_os = "macos")]. On iOS/tvOS/watchOS/visionOS generated keys are therefore always ephemeral: set_location() and set_access_control() are silently ignored because kSecAttrIsPermanent defaults to false. Restore the pre-kornelski#221 (v3.1.0) behavior: attach the public/private attrs on all targets (the AES branch stays macOS-only via a target-gated is_symmetric bool - non-macOS has no symmetric KeyType), and un-gate the location match so DataProtectionKeychain pushes kSecUseDataProtectionKeychain on non-macOS too, mirroring ItemAddOptions. kSecUseKeychain/FileKeychain remain macOS-only. The dictionary emitted on macOS is unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.
GenerateKeyOptions::to_dictionarybuilds thekSecPrivateKeyAttrssub-dictionary (carryingkSecAttrIsPermanentandkSecAttrAccessControl) on every target, but since #221 (d139535, first released in v3.2.0) only attaches it under#[cfg(target_os = "macos")]. On iOS/tvOS/watchOS/visionOS the generated key is therefore always ephemeral —set_location(...)andset_access_control(...)are silently ignored, becausekSecAttrIsPermanentdefaults to false.That cfg looks like a compile-convenience artifact of #221's AES handling (
KeyType::aes()is macOS-only) rather than an intentional platform decision: before #221 (up to v3.1.0) both sub-dictionaries were attached unconditionally, and Apple documents this exact pattern for iOS:kSecPrivateKeyAttrs: [kSecAttrIsPermanent: true, ...]withSecKeyCreateRandomKeyon all platforms.kSecPrivateKeyAttrsis iOS 2.0+,kSecAttrIsPermanentis iOS 2.0+,kSecAttrAccessControlis iOS 8.0+.kSecAttrIsPermanentandkSecAttrAccessControlinsidekSecPrivateKeyAttrsat create time.Changes:
kSecPublicKeyAttrs/kSecPrivateKeyAttrson all targets (the AES branch stays macOS-only via a target-gatedis_symmetricbool; non-macOS has no symmetricKeyType).locationmatch;Location::DataProtectionKeychainnow pusheskSecUseDataProtectionKeychainon non-macOS too, mirroringItemAddOptionsin item.rs. Apple: "You can safely use the key on all platforms" (it is implicit on iOS).kSecUseKeychain/FileKeychainremain macOS-only.The dictionary emitted on macOS is unchanged. Verified with the CI commands:
cargo check --all-features -p security-framework --target aarch64-apple-iosand--target x86_64-apple-darwin(plus aarch64-apple-darwin, default-feature builds, and clippy: no new warnings).🤖 Generated with Claude Code