Observer startup logs `ssl_external_kms_info` at INFO level

Self Checks

• I have read the Contributing Guide.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

OceanBase version

OceanBase CE 5.0.2.0, source revision d128661ca4f5b3d167c1928e556d70d2f901baef, Release+ASan.

Self Hosted

Self Hosted (Source)

Environment

Ubuntu 22.04.5 LTS, x86_64, one-zone loopback observer.

Steps to reproduce

Start a disposable observer with an ssl_external_kms_info value. The tested startup option was:

-o datafile_size=2G,log_disk_size=13G,memory_limit=6G,system_memory=1G,
   ssl_external_kms_info=454442465f535630335f53534c5f53454e54494e454c5f3230323630383331

The hexadecimal value decodes to EDBF_SV03_SSL_SENTINEL_20260831. Inspect the new run's observer.log; the complete authoritative log is bundled as artifacts/observer.log:

INFO [SHARE] ... Load config succ(
  name="ssl_external_kms_info",
  value="EDBF_SV03_SSL_SENTINEL_20260831")

The direct sink is src/share/config/ob_common_config.cpp:369:

LOG_INFO("Load config succ", K(name), K(value));

The same value is also present in the startup configuration dump. No SQL statement, KMS server, or external network connection is required.

artifacts.zip

✔️ Expected Behavior

Secret-bearing configuration items should be classified by name and redacted before any startup, configuration-dump, or error-path logging.

❌ Actual Behavior

The complete decoded ssl_external_kms_info value is written at INFO level during normal observer startup. This demonstrates disclosure to the observer log, not unprivileged OS-level log access.