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

Workaround/fix for env['varname'] after SECURITY-538

      With the blacklisting of getAt in SECURITY-538, this also also broken my ability to access arbitrary environment variables from the env global variable (by doing env['varname'] or similar).  I understand why getAt is blacklisted and the implications is has on other types, however I'm not sure those cases apply to the environment variable list.

      I found one work around is to whitelist method org.jenkinsci.plugins.workflow.support.actions.EnvironmentAction getEnvironment, which then requires the variable to be accessed as env.getEnvironment().get(varname). Is is possible to whitelist getAt for the env object but not anything else? I'm inclined to think so since it's done for integer access and string indexing but aren't sure what the whitelist method would be.

          [JENKINS-46000] Workaround/fix for env['varname'] after SECURITY-538

          Andy Neebel added a comment -

          Whitelisting getEnvironment isn't working, I don't get any exceptions but it doesn't appear to respect operating inside a withEnv block properly either.

          My script does work properly if I whitelist staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods getAt java.lang.Object java.lang.String but since this is now part of the blacklist, I don't think I want to be doing that.

          Andy Neebel added a comment - Whitelisting getEnvironment isn't working, I don't get any exceptions but it doesn't appear to respect operating inside a withEnv block properly either. My script does work properly if I whitelist staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods getAt java.lang.Object java.lang.String but since this is now part of the blacklist, I don't think I want to be doing that.

          Andy Neebel added a comment - - edited

          Ok, some additional lookup on how groovy handles properties showed me this syntax:
          env."${varname}"

          Using that works correctly. I'll close this issue since that's probably the right way to do things, but I think that env[varname] is more intuitive, is there any way to support that syntax again?

          Andy Neebel added a comment - - edited Ok, some additional lookup on how groovy handles properties showed me this syntax: env."${varname}" Using that works correctly. I'll close this issue since that's probably the right way to do things, but I think that env [varname] is more intuitive, is there any way to support that syntax again?

            Unassigned Unassigned
            andne Andy Neebel
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: