[JIRA] (JENKINS-44860) Disable masking of usernames

[oliver.lockwood@cantab.net (JIRA)]

Oliver Lockwood commented on JENKINS-44860

Re: Disable masking of usernames 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 pipeline script {{withCredentials([usernamePassword(credentialsId: 'MY_CRED_ID', usernameVariable: 'USER_ENV_VAR', passwordVariable: 'PASSWORD_ENV_VAR')]) { ... }}} to provide username and password as environment variables to the pipeline script closure and e.g. any shell commands within it 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. Jesse Glick 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. Add Comment

This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)

[oliver.lockwood@cantab.net (JIRA)]

Oliver Lockwood edited a comment on JENKINS-44860

Re: Disable masking of usernames

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')]) \{ ... }}}

to provide username and password as environment variables to the pipeline script closure and e.g. any shell commands within it

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

Add Comment

[oliver.lockwood@cantab.net (JIRA)]

Oliver Lockwood edited a comment on JENKINS-44860

Re: Disable masking of usernames

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:

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

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

Add Comment

[oliver.lockwood@cantab.net (JIRA)]

[oliver.lockwood@cantab.net (JIRA)]

[oliver.lockwood@cantab.net (JIRA)]

[henrist@henrist.net (JIRA)]

Henrik Steen commented on JENKINS-44860

Re: Disable masking of usernames

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

Add Comment

This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)

[nicolaw@tfb.net (JIRA)]

Nicola Worthington commented on JENKINS-44860

Re: Disable masking of usernames

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!

Add Comment

[jglick@cloudbees.com (JIRA)]

Jesse Glick commented on JENKINS-44860

Re: Disable masking of usernames

Trivially worked around FWIW: sh 'echo $USER_ENV_VAR | od -a'

Add Comment

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

[jglick@cloudbees.com (JIRA)]

Jesse Glick commented on JENKINS-44860

Re: Disable masking of usernames

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.

Add Comment

[oeuftete+jenkins@gmail.com (JIRA)]

oeuftete commented on JENKINS-44860

Re: Disable masking of usernames

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.

Add Comment

[jglick@cloudbees.com (JIRA)]

Jesse Glick commented on JENKINS-44860

Re: Disable masking of usernames

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.

Add Comment

[benoit@rudder.io (JIRA)]

Benoit Peck commented on JENKINS-44860

Re: Disable masking of usernames

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

Add Comment

[c.naslain@lectra.com (JIRA)]

Chris N. commented on JENKINS-44860

Re: Disable masking of usernames

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

Add Comment

[tim.jaacks@garz-fricke.de (JIRA)]

Tim Jaacks commented on JENKINS-44860

Re: Disable masking of usernames

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

Add Comment

[dmel50@hotmail.com (JIRA)]

Dimitris Meletiou commented on JENKINS-44860

Re: Disable masking of usernames

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

Add Comment

[stefan.thurnherr@gmail.com (JIRA)]

Stefan Thurnherr commented on JENKINS-44860

Re: Disable masking of usernames

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

Add Comment

[ppietraszkiewicz@psi.de (JIRA)]

Piotr Pietraszkiewicz commented on JENKINS-44860

Re: Disable masking of usernames

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

Add Comment

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)