const MAX_CHUNK_LEN: usize = 1000;Expand description
A first fix attempt (splitting the combined blob into one keychain entry
per field) turned out NOT to be sufficient: live-tested against a real
Cognito login, the exact same “Attribute ‘password’ is longer than
platform limit of 2560 chars” error still fired — a single token field
can itself exceed the cap depending on the app client’s token content
(custom claims, refresh token length), not just the three combined. So
each field is further chunked into as many entries as it takes, tracked
by an explicit <field>:count entry (write_chunked_field /
read_chunked_field below) — this holds regardless of any individual
token’s real-world size, instead of relying on an assumption about it.
A second live test with a 1800-char budget hit the SAME error again —
the keyring crate’s Windows backend checks
password.encode_utf16().count() * 2 > CRED_MAX_CREDENTIAL_BLOB_SIZE
(2560 bytes), but its own error message reports that raw byte count as
if it were a char limit (“longer than platform limit of 2560 chars”).
Since Windows stores the value as UTF-16 (2 bytes/char), the real
character budget is CRED_MAX_CREDENTIAL_BLOB_SIZE / 2 = 1280, not 2560
— keyring-2.3.3/src/windows.rs:182 vs. its own error text at
that crate’s error.rs (its TooLong message). 1800 was 40% over that
real limit. Budget well under 1280 here, not just under the misleading
2560 the error text implies.