sharanggupta opened a new pull request, #23909:
URL: https://github.com/apache/kafka/pull/23909
`ScramMessages.ServerFirstMessage.toMessage()` builds the SCRAM
server-first-message with
`String.format("r=%s,s=%s,i=%d", ...)`, and
`ScramCredentialUtils.credentialToString()`
persists the credential with `String.format("...,%s=%d", ...)`. Without an
explicit `Locale`,
`%d` follows the JVM's default locale, and on a broker whose default locale
uses native
digits (for example `ar-EG`, `fa-IR`, `bn-BD`, `ne-NP`; JDK 9+ CLDR data)
the iteration
count is emitted as `i=٤٠٩٦` instead of `i=4096`.
RFC 5802 requires ASCII digits, and `ServerFirstMessage` itself parses the
count with
`i=(?<iterations>[0-9]+)`, so every SCRAM handshake against such a broker
fails with
`SaslException: Invalid SCRAM server first message format: r=...,i=٤٠٩٦`
(non-Java clients
reject it the same way). The persisted credential string has the same
problem.
This passes `Locale.ROOT` to both `String.format` calls, as already done for
`toLowerCase()` under KAFKA-20638 and for the `tools`/`server-common`
modules under
KAFKA-20646 (which does not cover `clients`), and adds tests that switch the
default locale
to `ar-EG` and verify the message and the persisted credential still use
ASCII digits. The
other `String.format` calls in `ScramMessages` only use `%s` and are not
locale-sensitive.
Reproduced against the released `kafka-clients` 4.4.0 jar on JDK 25:
```
java -Duser.language=ar -Duser.country=EG ...
server-first-message on the wire = r=clientnonceservernonce,s=MDEy...,i=٤٠٩٦
client parse = FAILED: Invalid SCRAM server first
message format
```
Co-Authored-By: Claude Fable 5.1 <[email protected]>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
