allow GMS remote credential service to be used#193
Draft
inthewaves wants to merge 1 commit intoGrapheneOS:15-qpr2from
Draft
allow GMS remote credential service to be used#193inthewaves wants to merge 1 commit intoGrapheneOS:15-qpr2from
inthewaves wants to merge 1 commit intoGrapheneOS:15-qpr2from
Conversation
55ab7e3 to
fc45f72
Compare
Currently, GMS allows passkeys via hardware keys ("remote credentials" from a "remote device") by
its RemoteService, but this is being filtered as sandboxed Google Play doesn't result in system
services. The RemoteService is also expected to be set as an OEM config value in frameworks-res
(config_defaultCredentialManagerHybridService).
This will make it so that external devices (e.g. FIDO2 with NFC / USB) can be used with sandboxed
Google Play to register hardware keys in Vanadium / Chrome, along with improving hardware key
functionality in other apps that make credential requests with
android.credentials.CredentialManager (Context.CREDENTIAL_SERVICE) directly instead of contacting
Google Play services.
It still comes with the caveat that for some apps, Google has to be enabled as a credential service
under Settings > Passwords, passkeys & accounts, as sandboxed GMS services are not system credential
providers and have to be explicitly enabled as user credential providers. Apps that contact GMS
directly for credentials / passkeys still work without needing to enable Google as a credential
service (e.g., Vanadium / Chrome will fall back to contacting Play services directly if the
framework GetCredentialRequest fails which allows authentication to work without this patch, but
they don't such a fallback when creating credentials).
Test: atest CtsCredentialManagerTestCases
There's also FrameworksServicesTests:com.android.server.credentials, but currently it has some
Mockito failures
fc45f72 to
a2fd6a8
Compare
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.
Currently, GMS allows passkeys via hardware keys ("remote credentials" from a "remote device") by its RemoteService, but this is being filtered as sandboxed Google Play doesn't result in system services. The RemoteService is also expected to be set as an OEM config value in frameworks-res (
config_defaultCredentialManagerHybridService).This will make it so that external devices (e.g. FIDO2 with NFC / USB) can be used with sandboxed Google Play to register hardware keys in Vanadium / Chrome, along with improving hardware key functionality in other apps that make credential requests with
android.credentials.CredentialManager(Context.CREDENTIAL_SERVICE) directly instead of contacting Google Play services.It still comes with the caveat that for some apps, Google has to be enabled as a credential service under Settings > Passwords, passkeys & accounts, as sandboxed GMS services are not system credential providers and have to be explicitly enabled as user credential providers. Apps that contact GMS directly for credentials / passkeys still work without needing to enable Google as a credential service (e.g., Vanadium / Chrome will fall back to contacting Play services directly if the framework GetCredentialRequest fails which allows authentication to work without this patch, but they don't such a fallback when creating credentials).
Appears to resolve issues like ones described at https://discuss.grapheneos.org/d/12056-fido2-security-keys-on-grapheneos-a-summary/24 (tested on
release-keysuserbuild), though Discord passkey sign-in was also broken on stock OS when I tested it:Tests with Play services alpha 25.18.33 (260400-756823100), Vanadium 137.0.7151.72.1, Chrome Beta 138.0.7204.14, Brave 1.79.119:
Note that Brave doesn't require Google to be set as a credential provider under Settings > Passwords, passkeys & accounts, but all the other tested browsers and most other apps require this.