Hide the bgp password from logs

[fedepaol]

We expose the password in the logs in two places:

• when the speaker container dumps the configuration, because an error happened or because the log level is raised to debug
• in the reloader container, every time an frr configuration gets generated

Here, in both places we replace the password before logging.

[cgoncalves]

I'm of the opinion that logging the password when debug is on is useful when troubleshooting (only reason why one would enable debug)

[yuvalk]

password <retracted>
is more descriptive of what happend here IMHO

[fedepaol]

done, thanks!

[yuvalk]

I'm of the opinion that logging the password when debug is on is useful when troubleshooting (only reason why one would enable debug)

you can read the secret if what you need is (only) the password.
if you need the configuration, u can read it from debug log, and if you want to try it, you need to add the password in.

but getting the password from debug log is wrong.

consider the fact that logs can be stored on unencrypted disks and even in backups as well as (most common!) shipped to aggregator tools such as logstash/ splunk/ etc. so the opportunities of unauthorized access and data leak are growing.
best practices for secure coding is to treat passwords as secrets and as such mask them in logs. (or more generally - touch them as less as possible, dont carry them around, dont store them, etc.)

[fedepaol]

I'm of the opinion that logging the password when debug is on is useful when troubleshooting (only reason why one would enable debug)

you can read the secret if what you need is (only) the password. if you need the configuration, u can read it from debug log, and if you want to try it, you need to add the password in.

but getting the password from debug log is wrong.

consider the fact that logs can be stored on unencrypted disks and even in backups as well as (most common!) shipped to aggregator tools such as logstash/ splunk/ etc. so the opportunities of unauthorized access and data leak are growing. best practices for secure coding is to treat passwords as secrets and as such mask them in logs. (or more generally - touch them as less as possible, dont carry them around, dont store them, etc.)

This, plus the fact that we can still rely on vtysh show running-config if we suspect the passwords are wrong / there's a drift between the configured password and the expected one make me tend to keep the current version

[oribon]

lgtm