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!