The Bamboo password log obfuscation indeed masks anything that has the value of any password variable in the executing build/deployment context, which can have confusing effects for simple 'password' values that by chance occur elsewhere in the log as well, for example:
Say you have a global variable ${bamboo.defaultAdminPassword} with a value of 'admin' so that you can automate logging into Atlassian products started with the SDK's atlas-run-standalone command via the Bamboo Script task.
Using that password variable directly (e.g. for a REST API call) will properly yield a value masked with '********' in the log. However, if you also put an 'echo "Logging in as administrator ..."' command on top of the script, you will get a log output of "Logging in as ********istrator ...".
Put another way, anywhere the phrase 'admin' is contained in a log line, it will be masked as '********' because it happens to also be the value of a password variable.
From a technical perspective this is implemented via class PasswordMaskingLogMutator, which uses class PasswordMaskingUtils in turn. If you are curious and a licensee you can access the Bamboo source code to see exactly how this works.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.