Repository navigation
Truncate user names when updating user information - #804
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
There was a problem hiding this comment.
Code Review
This pull request introduces truncation of user-provided fields (user_name, user_display_name, and user_icon) to 64 bytes during credential updates to ensure they fit in storage while preserving UTF-8 boundaries, accompanied by a new unit test. Feedback recommends optimizing memory usage for this embedded environment by performing the string truncation in-place using String::truncate instead of allocating new strings, which also renders the ToString import unnecessary.
337bc26 to
8de687b
Compare
|
The truncation now happens in place with a local |
8de687b to
e509766
Compare
|
Thanks for the review! Summary of the update:
Formatting, clippy and the unit tests pass locally, including the new truncation test. |
e509766 to
cc78441
Compare
|
Hmm, maybe the Gemini review was inaccurate here. My own agent just suggested a similar change to this: For your inspiration. |
cc78441 to
75f602e
Compare
MakeCredential crops the user name, display name and icon to 64 bytes before storing a discoverable credential, with a comment explaining that this is done because the input is user provided. The updateUserInformation subcommand writes the same fields back without that crop. A platform holding a credMgmt token can therefore update a resident credential with a much longer user name. The serialization could then exceed the maximum value size of the persistent store, which fails the update. Truncate the fields to 64 bytes like MakeCredential does, reusing the same helper.
75f602e to
2568df2
Compare
MakeCredential crops the user name, display name and icon to 64 bytes before storing a discoverable credential, with a comment explaining that this is done because the input is user provided. The
updateUserInformationsubcommand writes the same fields back without that crop.A platform holding a credMgmt token can therefore update a resident credential with a much longer user name. The serialized credential then exceeds the maximum value size of the persistent store (1023 bytes with the default page size), and the whole subcommand fails with
CTAP2_ERR_VENDOR_INTERNAL_ERROR, even thoughMeasured with the test environment (which uses the real store): a stored credential is about 123 bytes, and a
user.nameof 900 bytes or more already makes the update fail on hardware.Apply the same 64-byte truncation as MakeCredential, so the stored credential stays within its expected size budget.