The git plugin and the git client plugin do not mask sensitive information. Masking is happening at a different level. I've removed the git plugin and git client plugin from the list of components.

I believe that the Jenkins security team would advise that displaying a credential value in a console log and relying on masking to hide the credential value is prone to many forms of attack.

For example, since the masking is likely applied to the entire console log, an attacker could echo the contents of a password guessing data file to the console log and watch for interesting output. No need to spend the effort creating branches, just list the contents of a file to the console log and see the results.

I suspect that the plugin providing the masking is the "mask passwords" plugin.

JENKINS-44860 would allow to prevent masking user names, which can be useful when they are service (~repo) specific and therefore identical to other common names.

The solution for passwords is easy, don't use passwords so trivial they have a real chance to appear in the build log.

Given multi-branch pipelines and similar setups that make org, repo, and branch names a structural part of the job name, there doesn't seem much benefit in special treatment for this very specific subset of output, as just echoing the job name would "unmask"the branch name anyway elsewhere.

The solution for passwords is easy, don't use passwords so trivial. ...

Easier said than done as it would require controlling users. I feel it also doesn't address the core issue, which is the sledgehammer approach to value masking, nor providing a testing mechanism on half the user/pass value.

Given multi-branch pipelines and similar setups ... just echoing the job name would "unmask" the branch name anyway elsewhere.

Are you sure? I tried echoing text containing the credential-matching text in the console and it came out obfuscated as four stars. I suspect echoing a different Jenkins variable with the same value would do the same. This also limits troubleshooting on more advanced operations that may require echoing to the console for such things as checking out multiple repos or any other situation where the values match an existing credential.

JENKINS-44860 is close enough to call a duplicate, but I think it's senseless to only focus on usernames. It should be broadened and renamed to something like, "Disable masking of non-credential values. ..." The real fix is to surgically apply masking where it is supposed to be applied.

At least this will be indexed in search engines so someone banging a head against the wall can tie back the issue more broadly to an existing bug report.

Are you sure? I tried echoing text containing the credential-matching text in the console and it came out obfuscated as four stars. I suspect echoing a different Jenkins variable with the same value would do the same

To clarify, I meant that all instances would be **** out, but since anyone looking at the build log would know the job name, it would then reveal whatever was masked, similar to your "branch name" example.

Easier said than done as it would require controlling users.

I feel like you probably have bigger problems than build output masking if that's the cause.

I feel it also doesn't address the core issue, which is the sledgehammer approach to value masking, nor providing a testing mechanism on half the user/pass value.

WDYM by 'testing'?

I can see an argument for certain build operations being exempt from masking, but in this case the problem seems to be shell script output. That's the part most likely to disclose secrets accidentally, an env or set call (in Batch) would do it, despite the author just wanting to log the build environment.

Please also note that for the case of your example:

If I know a username but I don't know a password, all I need to do is build a branch with my best guess, and Jenkins will tell me that my password guess is correct by showing me four stars. Similarly a validation is also offered for usernames.

If your expectation is that someone can be a committer to your project (they can define branch names) that is built with credentials being defined and could not take an action that would reveal the password, that is fairly unrealistic. They can just change the Jenkinsfile, pom.xml, build.gradle, or just write a test that always writes all env vars to stderr in a scrambled form (base64, rot13) that escapes masking.