+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.

Hi Tim,
I cannot see the workaround you propose can be applied universally. We have credentials to github defined as private key with passphrase and username git.
What this makes is that everwhere 'git' string shows up we get it replaced with ****.

E.g. ssh://git@github.com/ourorg/repo.git becomes ssh://***@**hub.com/ourorg/repo.***

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...