mirror of
https://github.com/rustfs/rustfs.git
synced 2026-07-26 08:18:18 +00:00
Zhengchao An
d874831cec
* fix(kms): do not include secret value in static KMS format error The malformed-format error message in build_static_kms_config embedded the raw env var value. The most likely misconfiguration is setting RUSTFS_KMS_STATIC_SECRET_KEY to the bare base64 key without the <key-name>: prefix, in which case the full secret key material would be written to startup logs. Drop the value from the message, matching the equivalent parsing error in KmsConfig::from_env(). * chore(security): add guardrails against secret values in error strings Follow-up to the PR #5222 review finding fixed in PR #5243: a config value that fails secret-format parsing is typically the raw secret itself, and error messages are log content — they propagate via ? and are printed by startup/error logging far from the construction site. Three layers so this class of leak is caught earlier next time: - security-advisory-lessons: state explicitly that error/panic messages are log content; parse-failure hints must name the env var and expected format, never echo the input. Add a matching review prompt. - adversarial-validation: add a security-reviewer probe that greps error-construction sites on secret-bearing config paths for interpolation of the raw value, including the duplicated-parse trap where the leak hid. - check_logging_guardrails.sh: mechanical backstop — flag inline format interpolation of secret-named identifiers (secret/password/passwd/ private_key) in checked files; add crates/kms/src/config.rs (the twin parse site) to the checked list. Verified the check passes on the fixed tree and catches the original leak at rustfs/src/init.rs:399.