In the same vein as zett42 I created a groovy library to wrap his method for easy use in my pipelines.

I call the file unsafeEcho.groovy and call it via 

unsafeEcho "SHORT_BUILD_VERSION: $SHORT_BUILD_VERSION"

#!/usr/bin/env groovy

// Workaround for "Print message" that is displayed by original echo step if the message
// contains a value of an environment variable or a pipeline parameter.
//
// WARNING: This disables masking of secrets in the output, so don't call it 

void call( String msg ) { 
    withContext( new unsafeEchoClearer() ) { 
        echo msg 
    } 
}


// Clears all environment variables, to be used from withContext{}.
class unsafeEchoClearer extends org.jenkinsci.plugins.workflow.steps.EnvironmentExpander {
    @NonCPS
    void expand( hudson.EnvVars env ) throws IOException, InterruptedException {
        env.clear()    
    }    
}

Been affected by this issue as well and debugged further. Based on my findings the "flaw" is in the attempt of locating environment variables that might be credentials bindings.

 https://github.com/jenkinsci/workflow-cps-plugin/blame/master/src/main/java/org/jenkinsci/plugins/workflow/cps/DSL.java#L240

My "slightly more than minimal failing" example after configuring a secret text with the id hello is:

withEnv(['FOO=bar']) {
    echo "Testing bar world"
    withCredentials([string(credentialsId: 'hello', variable: 'MY_SECRET')]) {
        echo "Testing bar world"
        withEnv(['BAR=baz']) {
            echo "Testing bar world"
            withCredentials([string(credentialsId: 'hello', variable: 'MY_OTHER_SECRET')]) {
                echo "Testing bar world"
            }
        }
    }
}

The issue is that we can currently not cleanly separate credentials from other env variables. As a result, all env vars are effectively treated as credentials and their output is masked. That's also why I don't think this is an issue with Blue Ocean.

I think the system would function as intended if only env vars used as credentials were passed in as constructors to ArgumentsActionImpl at https://github.com/jenkinsci/workflow-cps-plugin/blame/master/src/main/java/org/jenkinsci/plugins/workflow/cps/DSL.java#L246.

jglick what would be a clean way to only determine env vars that were added as credentials?

Well known limitation of the current design. Essentially the same problem as what is described in JENKINS-47101, though with different symptoms. APIs to solve this have been discussed recently, but no promises.

jglick JENKINS-47101 seems to be the conflicting requirement to suppress credentials in a step, which is different from this issue where non-credentials are suppressed.

Where are these discussions taking place? Would be happy to help!

What if `EnvironmentExpander` had a method to yield only env vars that represent a `Secret`. With that the env vars passed into the sanitization could only retain those and argument masking should work as intended!?

JENKINS-47101 seems to be the conflicting requirement

Yes, as I said the symptoms are different. The underlying problem is the lack of an API to determine whether environment variables are sensitive, something like AbstractBuild.getSensitiveBuildVariables but suited to Pipeline’s needs; in lieu of that, workflow-cps assumes most variables are sensitive, but makes exemptions for a fixed list of common system variables. And yes EnvironmentExpander is the likely locus of such a new API, such as Set<String> getSensitiveVariables().