UsernamePasswordMultiBinding could be patched to to treat usernameVariable as optional (move it to a @DataBoundSetter, document that it may be left blank).

We came across this issue last week as well and, having discovered this issue, are contemplating contributing a fix.

Just to be clear, we'd like to:

• use the username/password credentials type
• use the following pipeline script to provide username and password as environment variables to the pipeline script closure and e.g. any shell commands within it:

  • withCredentials([usernamePassword(credentialsId: 'MY_CRED_ID',
                                      usernameVariable: 'USER_ENV_VAR',
                                      passwordVariable: 'PASSWORD_ENV_VAR')]) {
       ...
    }

• have any instances of whatever the password is be masked in console output
• NOT have any instances of whatever the username is masked in console output.

This would then correlate correctly with the view on the jenkinsUrl/credentials page, which shows user-name/****** (description) in the Name column for credentials of this type.

jglick we already found the UsernamePasswordMultiBinding class; but it looks to us (perhaps naively?) that the return value of the `bind()` method is used in BindingStep.Execution.start() both for actually providing the environment variables (through the use of EnvironmentExpander) and for obfuscating the secrets into **** (through the use of Filter).  So it's not clear to me how the patch you're suggesting would allow us to still provide the username from a Credential without it being obfuscated.  Have I misunderstood your comment?  Many thanks.

I made a new PR for this in July, but seems I didn't get it linked up here correctly. https://github.com/jenkinsci/credentials-binding-plugin/pull/50

Fixing this would be wonderful. Console logs with every occurrence of `jenkins`, `release`, `artifactory`, `git` and `user` etc being masked out can make debugging really quite tedious!

Trivially worked around FWIW:

sh 'echo $USER_ENV_VAR | od -a'

PR 54 skips username binding entirely, so suitable for the common case that the username portion of the credentials is something generic enough to be hard-coded.

I am not sure PR 54 addresses the spirit of the request.  Or really solves anything... why wouldn't a user just update their secret to just secret text if they need to hardcode the username?

There is value in storing the credential as a username and a password. Usernames are going to be things like "`jenkins`, `release`, `artifactory`, `git` and `user`" as the opener and commenters have noted.  The workaround noted above does not address the types of problems the user name masking causes... I believe for most users, and certainly for me, these are issues with console log processing, e.g.

00:16:31.073 [Scala Compiler] [ERROR] Can't create blame requests for some affected files:
00:16:31.073 [Scala Compiler] [ERROR] - Skipping non-workspace file /home/****/workspace/somebuild/someFile.scala
00:16:31.073 [Scala Compiler] [ERROR] - Skipping non-workspace file /home/****/workspace/somebuild/someOtherFile.scala

... where `jenkins` was filtered out in the console log.

why wouldn't a user just update their secret to just secret text if they need to hardcode the username?

In some cases, you cannot, because the credentials are also being used by other plugins which expect username/password.

I have a mind to develop a full fix for this at some point, but it is on my back burner. Will likely also need dedicated support in pipeline-model-definition-plugin.

We have the same problem and I must say this is a PITA.

The username is not a secret and should not be hidden, especially since the method used is to grep any string that 'may' contain the username which is clunky at best.

Moreover, the username is often a common name, which result in logs that are totally mangled and unreadable, all our url are non clickable because they contain the 3 letters 'git'.

This renders the credential feature an anti-feature for us.

Please remove the login from being masked! And if you insist on keeping it, please add an option to disable this feature.

Thank you

+1 to fix this. very painful with configuration where the credential user is also the jenkins user (username is in home dir!!!).

+1 from me. This is REALLY annoying. We are using "jenkins" as a username as well, while our Jenkins instance is running under "http://our-company-intranet/jenkins/". This bug changes all URLs in the job log to "http://our-company-intranet/****", making them unusable.

+1 to fix, I need to print urls but they are partially masked as they happen to contain a username somewhere in the FQDN

+1 to fix, parsing the console log with the warnings-ng jenkins plugin doesn't work otherwise:

10:19:08  [Java] [-ERROR-] Can't resolve absolute paths for some files:
10:19:08  [Java] [-ERROR-] - /export/jenkins/workspace/_jenkins-warnings-to-warnings-ng/****-core/src/main/java/com/company/****/mypackage/SomeClass.java
[...]
10:19:08  [Java] [-ERROR-] Can't create fingerprints for some files:
10:19:08  [Java] [-ERROR-] - '/export/jenkins/workspace/_jenkins-warnings-to-warnings-ng/****-core/src/main/java/com/company/****/mypackage/SomeClass.java', IO exception has been thrown: java.nio.file.NoSuchFileException: /export/jenkins/workspace/_jenkins-warnings-to-warnings-ng/****-core/src/main/java/com/company/****/mypackage/SomeClass.java
[...]
10:19:08  [Java] [-ERROR-] Git blame errors:
10:19:08  [Java] [-ERROR-] - no blame results for request <****-core/src/main/java/com/company/****/mypackage/SomeClass.java - [82]>.

+1 to fix, scrambles commands in the console output where it needs not to, scrambles URLs

I want to repeat my comment on Jenkins-63618 here:

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.

+1 to fix this issue, and there are other reasons beyond URL scrambling and debugging.

Agreed, this "feature" is highly annoying, but I want to draw attention to the obvious: this is really only a problem when you're using a credentials binding type that includes a username, e.g. usernamePassword.

Workaround:

We all have the option of simply not using the usernamePassword binding, and using the string type instead. This is precisely what I've done to prevent the annoying console obfuscation that requires me to search/replace strings every time I copy/paste from Jenkins console for communication purposes, e.g. github issues. Note that you can't just add the string credential and start using it, you also have to delete the old usernamePassword credentials.

References: [plugin docs|https://www.jenkins.io/doc/pipeline/steps/credentials-binding/] and 

To support this argument, I'd also say, why would it ever be necessary to store usernames - which are non-sensitive data, right?? - in Jenkins Credentials stores? I would say many could benefit from simply moving away from usernamePassword to using string binding, and use a simple convention that the credentialsId contain (or be equal to) the username in question.

Implemented. No change is made to the behavior of existing credentials, but you can now switch them to treat username as nonsecret, and newly created credentials will behave that way by default.

jglick, how to switch? Can't find that anywhere. And I still see masked usernames in current LTS Jenkins with newly created (Vault) credentials (but using generic bindings in the job configs to access them).

I am not familiar with the Vault plugin(s). The option is present in generic username/password credentials.

Ah, OK. Thanks for clarifying. Will open a ticket for the vault plugin, then...