Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-27382

EnvInjectPluginAction::buildEnvVars() injects masks instead of passwords to the environment

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • envinject-plugin, gradle-plugin
    • None
    • EnvInject version 1.91 and version 1.91.1

      I created a local and global password.
      In a shell step the password can be used successfully.
      In the next build step of my build I have the Gradle plugin, the password arrives as asterisks.

      As a work-around I have switched to use the MaskPassword plugin.

      Test Script build.gradle:

      task showGlobalEnv << {
      println '\''Test match:'\'' + (System.env.TEST_ENV == 'T123')
      System.env.TEST_ENV.each

      { println it }

      }

      Output from version 1.90 (successful):
      Test match:true
      T
      1
      2
      3

      Output from version 1.91 (failure):
      Test match:false
      *
      *
      *
      *
      *
      *
      *
      *

          [JENKINS-27382] EnvInjectPluginAction::buildEnvVars() injects masks instead of passwords to the environment

          Marcus Collins created issue -

          Felix Nawroth added a comment -

          The same happens with envinject 1.91.1 and maven 2.8/2.9, Jenkins 1.596.2. No difference whether the password is defined locally or globally.

          Passing the passwords as JVM parameters works (-Dsecret=${PASSWD_VAR}, while accessing the environment variable in Maven does not and will yield asterisks instead.

          Felix Nawroth added a comment - The same happens with envinject 1.91.1 and maven 2.8/2.9, Jenkins 1.596.2. No difference whether the password is defined locally or globally. Passing the passwords as JVM parameters works (-Dsecret=${PASSWD_VAR}, while accessing the environment variable in Maven does not and will yield asterisks instead.

          Kevin Mayfield added a comment -

          I experienced the same when invoking Gradle with the Gradle plugin, and options of -Pmvn_password=${MVN_PASSWORD}.
          Reverted back to 1.90 to solve problem.

          Kevin Mayfield added a comment - I experienced the same when invoking Gradle with the Gradle plugin, and options of -Pmvn_password=${MVN_PASSWORD}. Reverted back to 1.90 to solve problem.

          Kevin Mayfield added a comment -

          Problem still exists in 1.91.2

          Kevin Mayfield added a comment - Problem still exists in 1.91.2
          Daniel Beck made changes -
          Link New: This issue is duplicated by JENKINS-28116 [ JENKINS-28116 ]

          Aleksandr Borovkov added a comment -

          Problems still exists in 1.91.3
          The password arrives as asterisks use msbuild plugin.
          Reverted back to 1.90 to solve problem

          Aleksandr Borovkov added a comment - Problems still exists in 1.91.3 The password arrives as asterisks use msbuild plugin. Reverted back to 1.90 to solve problem

          Christian Häussler added a comment -

          +1

          Christian Häussler added a comment - +1
          Aleksandr Borovkov made changes -
          Priority Original: Major [ 3 ] New: Critical [ 2 ]

          Christopher Miller added a comment -

          We just upgraded from 1.90 to 1.94 and the problem cropped up. Going to rollback to 1.90. This makes the sensitive variable functionality useless outside of the Execute Shell step. The password is passed as **** to all other plugins that make use of the EnvVars object.

          Christopher Miller added a comment - We just upgraded from 1.90 to 1.94 and the problem cropped up. Going to rollback to 1.90. This makes the sensitive variable functionality useless outside of the Execute Shell step. The password is passed as **** to all other plugins that make use of the EnvVars object.

          Steven Christou added a comment -

          I believe this is a regression from commit d50c5. I did a git checkout for each commit between 1.90, and 1.91, and found this commit to inject the * characters.

          Steven Christou added a comment - I believe this is a regression from commit d50c5 . I did a git checkout for each commit between 1.90, and 1.91, and found this commit to inject the * characters.

            recena Manuel Recena Soto
            mbtc Marcus Collins
            Votes:
            9 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated:
              Resolved: