[JENKINS-44860] Allow usernames to be left unmasked in build log

[jglick]

JENKINS-44860: Allows usernames to left unmasked in the build log. Continues #50 (and thus #44).

Note that this functionality is available only in Scripted syntax, or at least when explicitly using the withCredentials step. In Declarative using the credentials syntax in an environment block, https://github.com/jenkinsci/pipeline-model-definition-plugin/blob/15978cd172a8d34e2cd6bf8a6bfeaa5514d44dad/pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy#L463-L475 calls https://github.com/jenkinsci/pipeline-model-definition-plugin/blob/15978cd172a8d34e2cd6bf8a6bfeaa5514d44dad/pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/credentials/impl/UsernamePasswordHandler.java#L61-L68 which will continue to mask the username. Adding a third binding in which it is unmasked would do no good, since it would still be considered secret due to the second binding. Changing the second binding to set showUsername to true would potentially be a security vulnerability, in case a user expected the username from some credentials to be sensitive: merely upgrading the credentials-binding plugin would quietly begin printing the username in new builds. The problem is that Declarative tries to autodetect the right bindings to use based on the credentials type, which is convenient but forecloses the possibility of (compatibly) adding alternative behaviors: there is no place in the syntax for selecting a binding or a binding option.

[bitwiseman]

Note that this functionality is available only in Scripted syntax, or at least when explicitly using the withCredentials step.

This adds showUserName as a property of the credential. Why would this not be something that could be made to work in Declarative?

[jglick]

This adds showUserName as a property of the credential. Why would this not be something that could be made to work in Declarative?

Because the Declarative syntax is simply

environment {
    MYCREDS = credentials('the-credentials-id')
}

You do not get a choice of which binding to use, much less its specific options.

[bitwiseman]

This adds showUserName as a property of the credential. Why would this not be something that could be made to work in Declarative?

Because the Declarative syntax is simply

environment {
    MYCREDS = credentials('the-credentials-id')
}

You do not get a choice of which binding to use, much less its specific options.

Could we make a setting on the credential itself to control whether the name is exposed by default, hidden by default, or not allowed? This seems like a behavior the admins who control the credentials should have some control over.

[daniel-beck]

Could we make a setting on the credential itself

I think I remember talking about this with @jeffret-b a while back, IIRC we agreed that this is where it should be as need to mask might depend on the kind of username it is.

[jglick]

Could become a field in UsernamePasswordCredentialsImpl if we wish to transfer control from the Pipeline author to the credentials creator. Or we can just declare that usernames are unconditionally public once you upgrade the plugin, as in #44/#50, though it scares me some. Note that currently the username is saved and round-tripped in plain-text as a String, not a Secret, and is also shown in the job config dropdown via StandardUsernamePasswordCredentials.NameProvider. Happy to prototype alternate behaviors if there is any consensus.

[jeffret-b]

Yes, we did discuss adding some properties on a credential to control things like this -- visibility and other usage behaviors. It does transfer control from the pipeline author to the credential creator, but it makes sense that the owner / creator of the credential should be able to control things like this. It's been quite a while since I looked into things with this, though.

[jglick]

Could we make a setting on the credential itself

Check #132.