taoran92 opened a new issue, #10467:
URL: https://github.com/apache/paimon/issues/10467
### Search before asking
- [x] I searched in the issues and found nothing similar.
### Paimon version
2.2-SNAPSHOT, commit `ff2f1cec131542965c57e6808b8d5e8e95be8125`.
### Compute Engine
Java API, OpenJDK 11.
### Minimal reproduce step
Call `DLFDefaultSigner.authorization()` with a fixed request, timestamp,
region, and a synthetic non-ASCII secret such as `"secret\u5bc6\u94a5"`.
Run separately with `-Dfile.encoding=UTF-8` and
`-Dfile.encoding=ISO-8859-1`. The generated signatures differ.
### What doesn't meet your expectations?
Signatures should be independent of the JVM default charset.
`DLFDefaultSigner` uses implicit encoding in two places:
```java
// Signing-key derivation
("aliyun_v4" + dlfToken.getAccessKeySecret()).getBytes()
// HMAC input
data.getBytes()
```
Non-ASCII secrets or direct HMAC inputs can therefore produce inconsistent
signatures. Paths, query parameters, and bodies already use UTF-8 for digest
calculation and do not independently trigger this issue.
### Anything else?
Use `getBytes(UTF_8)` in both places, consistent with `DLFOpenApiSigner` and
`DLFOpenApiV4Signer`. Add fixed expected-signature tests under both UTF-8 and a
non-UTF-8 default charset.
### Are you willing to submit a PR?
- [x] I'm willing to submit a PR!
--
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]
