[Keychain] Prevent keychain access from prompting user for permissions on macOS #75
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
|
Will add a corresponding bug number in PR description after getting PR ready for release. |
Coverage Report 1Affected Products
Test Logs |
ncooke3
changed the title
ncooke3
force-pushed
the
nc/macos-keychain-fix
branch
from
7487b41 to
7213821
Compare
charlotteliang
approved these changes
Aug 25, 2022
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.
Context
This PR adds the
kSecUseDataProtectionKeychainsearch attribute to the keychain wrapper APIs inGULKeychainStorage.handGULKeychainUtils.h. The search key will make the macOS keychain behave like the iOS-style keychain. This is needed to avoid the keychain access pop-ups that occur when a macOS-style keychain is accessed.GoogleUtilities exposes two public headers that facilitate interaction with the Keychain:
GULKeychainStorage.handGULKeychainUtils.h.GULKeychainStorage.himplementation usesGULKeychainUtils.hto actually make call the Keychain's native APIs. Because of this, adding thekSecUseDataProtectionKeychainwas, at minimum, required inGULKeychainUtils.h. But, to avoid future implementation changes whereGULKeychainStorage.hno longer usesGULKeychainUtils.has an implementation detail, I have ensured the key is inject at theGULKeychainStorage.hlevel. This will ensure that using both headers will always result in a querying the keychain with thekSecUseDataProtectionKeychainflag set totrue, now and in the future.Additionally, explicitly setting
kSecUseDataProtectionKeychaintotrueonly really affects macOS because the key is set totrueby default. For macOS, settingkSecUseDataProtectionKeychaintotruerequires that targets that include the GoogleUtilities framework are signed with a provisioning profile that includes the Keychain Sharing capability.More details at go/firebase-macos-keychain-popups
Outstanding work (in order of planned completion)
GULKeychain*and targeting macOS.GULKeychainStorage.handGULKeychainUtils.hregarding macOS-specific constraints.Fixes