Private key password is logged at debug level together with other HTTP[S]-based listener settings

[mxchina]

Describe the bug

When the log level is set to debug, the password for the private key is found in the log.
I don't think any sensitive information should be recorded in the log at any log level.
The community should desensitize the log output for sensitive information.

Reproduction steps

1. rabbitmq version
   3.12.6

2. the example private key: 63nwuzRgbEel68MRTlaM

3. cat /etc/rabbitmq/rabbitmq.conf
   ......
   management.ssl.port = 15672
   management.ssl.cacertfile = /etc/rabbitmq/ssl/ca.crt
   management.ssl.certfile = /etc/rabbitmq/ssl/rabbitmq_server.crt
   management.ssl.keyfile = /etc/rabbitmq/ssl/rabbitmq_server.key
   management.ssl.password = 63nwuzRgbEel68MRTlaM
   management.ssl.honor_cipher_order = true
   management.ssl.honor_ecc_order = true
   management.ssl.client_renegotiation = false
   management.ssl.secure_renegotiate = true
   management.ssl.versions.1 = tlsv1.2
   ......

---

cat rabbitxxxxxxxxxxxxxxx.log
......
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> Starting HTTP[S] listener with transport ranch_ssl, options [{ip,
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> {172,17,2,236}},
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> {port,15672},
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> {versions,
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> ['tlsv1.2']},
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> {client_renegotiation,
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> false},
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> {secure_renegotiate,
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> true},
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> {honor_ecc_order,
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> true},
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> {honor_cipher_order,
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> true},
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> {password,
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> "63nwuzRgbEel68MRTlaM"},
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> {cacertfile,
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> "/etc/rabbitmq/ssl/ca.crt"},
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> {keyfile,
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> "/etc/rabbitmq/ssl/rabbitmq_server.key"},
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> {certfile,
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> "/etc/rabbitmq/ssl/rabbitmq_server.crt"},
2023-09-28 07:24:16.905485+00:00 [debug] <0.1766.0> {port,15672}
......

Expected behavior

Desensitize the password of the private key, such as using *** instead

Additional context

No response

[michaelklishin]

I disagree.

The purpose of debug logging is to inspect the state of the system. No one should run with this log level at all times. It is meant to be used in development and with rabbitmqctl set_log_level debug. It is not the default log level unless you build and run a RabbitMQ node with Bazel or Make.

Since debug logging is not on by default and the message is only logged at node startup time, I think we will leave it as is. Or we could not log any listener details at all, I don't have a strong opinion.

[michaelklishin]

The team decided that no logging the options should be fine, that information was at some point much more relevant but not any more #9573.