[JIRA] (JENKINS-37324) We would like a more meaningful description of a step

[svano...@cloudbees.com (JIRA)]

Title: Message Title

Sam Van Oort commented on JENKINS-37324   Re: We would like a more meaningful description of a step To capture discussion from today with Jesse Glick and James Dumay and others: Requirements added: One of the implementation challenges here is that we need to mask sensitive variables in the step description (example: an access token used in a shell command invoking AWS CLI, bound into the shell command by environment variable). This information CANNOT be stored or displayed in a step We also need to limit the size of data that is stored in recorded Step in case (for example writeFile) large data is being passed via variables Implementation: We will use the EnvVars (the only thing we have to work with here) to detect sensitive strings included in String parameters, by looking for the value of EnvVars in that content. Where potentially hidden content is present, initially none of the String's content will be stored or displayable. Later we may try to replace the variable content with the EnvVars name, i.e. "my password is $passwordVar" which would execute as 'my password is s3cretC0ntent' becomes 'my password is $ {passwordVar} ' (so we know a variable was used). This is desirable and helpful for users but risks accidentally exposing a secret if present in normal String content somewhere. To reduce false positives, the safe/standard global environment variables for a pipeline will be removed from this list of EnvVars We may also attempt to remove local computer environment variables as with https://github.com/jenkinsci/docker-workflow-plugin/blob/916bdb728fdff51709933e653ce6baa867b7bebb/src/main/java/org/jenkinsci/plugins/docker/workflow/WithContainerStep.java#L125-L127 Comment: Lots of discussion about how to separate sensitive and nonsensitive environment variable content (markers for data, whitelist/blacklist, or custom information in their EnvVars definitions) – Jesse Glick has suggested a clever approach: to play with a different way of detecting secrets you would patch `BindingStep` and `MaskPasswordsBuildWrapper` to, say, not just set `PASSWORD=s3cr3t` but also `PASSWORD+SECRET=true`, and then document this somewhere like in `EnvironmentExpander` Add Comment   This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.