The client_id field in auth.proto (line 15) is declared as bytes, which in proto3 carries no length restriction. The comment on lines 13–14 states the field is "exactly nine raw UTF-8 bytes", but that invariant is nowhere enforced by the proto schema.
The HMAC at field 3 covers (client_id || timestamp). If client_id is shorter or longer than nine bytes the HMAC still verifies cleanly as long as both sides encode the same byte sequence, so a non-nine-byte value passes the authentication check without triggering any schema-level rejection.
Add (validate.rules).bytes.len = 9 via protoc-gen-validate, or at minimum add a comment on the hmac field stating that callers must validate the nine-byte length before computing or verifying the tag.
The
client_idfield inauth.proto(line 15) is declared asbytes, which in proto3 carries no length restriction. The comment on lines 13–14 states the field is "exactly nine raw UTF-8 bytes", but that invariant is nowhere enforced by the proto schema.The HMAC at field 3 covers
(client_id || timestamp). Ifclient_idis shorter or longer than nine bytes the HMAC still verifies cleanly as long as both sides encode the same byte sequence, so a non-nine-byte value passes the authentication check without triggering any schema-level rejection.Add
(validate.rules).bytes.len = 9via protoc-gen-validate, or at minimum add a comment on thehmacfield stating that callers must validate the nine-byte length before computing or verifying the tag.