• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • script-security-plugin
    • None
    • Jenkins v2.84, Pipeline: Groovy v2.41

      Here's a minimal example that works outside of sandbox but fails in sandbox:

      def func = { 1 }; 
      this.func2 = { 1 }; 
      assert 1 == func(); 
      assert 1 == func2.call(); 
      assert 1 == func2(); // this line fails 

      It appears as if the it.call() -> it() syntactic sugar, which afaik is part of the language spec, is not honored in restricted sandbox under certain circumstances that make it difficult to create dynamic functions; ideally, I'd like to do something resembling:

      def files = sh(returnStdout:true,script:'ls vars/*.groovy'}.trim();
      for(file in files){this."${file.subscript(5,file.size()-7)}" = load file; }

      Unlike method signatures which can be whitelisted, because this is a language feature it does not appear to be possible to enable.

          [JENKINS-50906] Restricted sandbox breaks Callable sugar

          Fred Spieler created issue -
          Fred Spieler made changes -
          Description Original: Here's a minimal example that works when running in groovysh but fails when running in Jenkinsfile:

          \{\{def func = \{ 1 }}}
           \{\{ this.func2 = \{ 1 }}}
           \{\{ assert 1 == func()}}
           \{\{ assert 1 == func2.call()}}
           \{\{ assert 1 == func2() // this line fails}}

          It appears as if the it.call() -> it() syntactic sugar, which afaik is part of the language spec, is not honored when assigning callable properties to WorkflowScript ({{this}}).
          New: Here's a minimal example that works when running in groovysh but fails when running in Jenkinsfile:

          {{ def func = \{ 1 } }}
          {{ this.func2 = \{ 1 } }}
          {{ assert 1 == func() }}
          {{ assert 1 == func2.call() }}
          {{ assert 1 == func2() // this line fails }}

          It appears as if the it.call() -> it() syntactic sugar, which afaik is part of the language spec, is not honored when assigning callable properties to WorkflowScript ({{this}}).
          Fred Spieler made changes -
          Description Original: Here's a minimal example that works when running in groovysh but fails when running in Jenkinsfile:

          {{ def func = \{ 1 } }}
          {{ this.func2 = \{ 1 } }}
          {{ assert 1 == func() }}
          {{ assert 1 == func2.call() }}
          {{ assert 1 == func2() // this line fails }}

          It appears as if the it.call() -> it() syntactic sugar, which afaik is part of the language spec, is not honored when assigning callable properties to WorkflowScript ({{this}}).
          New: Here's a minimal example that works when running in groovysh but fails when running in Jenkinsfile in restricted sandbox:

          {{ def func = \{ 1 } }}
          {{ this.func2 = \{ 1 } }}
          {{ assert 1 == func() }}
          {{ assert 1 == func2.call() }}
          {{ assert 1 == func2() // this line fails }}

          It appears as if the it.call() -> it() syntactic sugar, which afaik is part of the language spec, is not honored when assigning callable properties to WorkflowScript ({{this}}).
          Fred Spieler made changes -
          Description Original: Here's a minimal example that works when running in groovysh but fails when running in Jenkinsfile in restricted sandbox:

          {{ def func = \{ 1 } }}
          {{ this.func2 = \{ 1 } }}
          {{ assert 1 == func() }}
          {{ assert 1 == func2.call() }}
          {{ assert 1 == func2() // this line fails }}

          It appears as if the it.call() -> it() syntactic sugar, which afaik is part of the language spec, is not honored when assigning callable properties to WorkflowScript ({{this}}).
          New: Here's a minimal example that works when running in groovysh but fails when running in Jenkinsfile in restricted sandbox:

          def func = \{ 1 }
          this.func2 = \{ 1 }
          assert 1 == func()
          assert 1 == func2.call()
          assert 1 == func2() // this line fails

          It appears as if the it.call() -> it() syntactic sugar, which afaik is part of the language spec, is not honored when assigning callable properties to WorkflowScript ({{this}}).
          Fred Spieler made changes -
          Description Original: Here's a minimal example that works when running in groovysh but fails when running in Jenkinsfile in restricted sandbox:

          def func = \{ 1 }
          this.func2 = \{ 1 }
          assert 1 == func()
          assert 1 == func2.call()
          assert 1 == func2() // this line fails

          It appears as if the it.call() -> it() syntactic sugar, which afaik is part of the language spec, is not honored when assigning callable properties to WorkflowScript ({{this}}).
          New: Here's a minimal example that works when running in groovysh but fails when running in Jenkinsfile in restricted sandbox:

          {{def func = \{ 1 }}}
          {{ this.func2 = \{ 1 }}}
          {{ assert 1 == func()}}
          {{ assert 1 == func2.call()}}
          {{ assert 1 == func2() // this line fails}}

          It appears as if the it.call() -> it() syntactic sugar, which afaik is part of the language spec, is not honored when assigning callable properties to WorkflowScript ({{this}}).
          Fred Spieler made changes -
          Description Original: Here's a minimal example that works when running in groovysh but fails when running in Jenkinsfile in restricted sandbox:

          {{def func = \{ 1 }}}
          {{ this.func2 = \{ 1 }}}
          {{ assert 1 == func()}}
          {{ assert 1 == func2.call()}}
          {{ assert 1 == func2() // this line fails}}

          It appears as if the it.call() -> it() syntactic sugar, which afaik is part of the language spec, is not honored when assigning callable properties to WorkflowScript ({{this}}).
          New: Here's a minimal example that works when running in groovysh but fails when running in Jenkinsfile in restricted sandbox:

          {{def func = \{ 1 };}}
          {{ this.func2 = \{ 1 };}}
          {{ assert 1 == func();}}
          {{ assert 1 == func2.call();}}
          {{ assert 1 == func2(); // this line fails}}

          It appears as if the it.call() -> it() syntactic sugar, which afaik is part of the language spec, is not honored when assigning callable properties to WorkflowScript ({{this}}).
          Fred Spieler made changes -
          Description Original: Here's a minimal example that works when running in groovysh but fails when running in Jenkinsfile in restricted sandbox:

          {{def func = \{ 1 };}}
          {{ this.func2 = \{ 1 };}}
          {{ assert 1 == func();}}
          {{ assert 1 == func2.call();}}
          {{ assert 1 == func2(); // this line fails}}

          It appears as if the it.call() -> it() syntactic sugar, which afaik is part of the language spec, is not honored when assigning callable properties to WorkflowScript ({{this}}).
          New: Here's a minimal example that works when running in groovysh but fails when running in Jenkinsfile in restricted sandbox:

          {{def func = \{ 1 }; }}
          {{this.func2 = \{ 1 }; }}
          {{assert 1 == func(); }}
          {{assert 1 == func2.call(); }}
          {{assert 1 == func2(); // this line fails }}

          It appears as if the it.call() -> it() syntactic sugar, which afaik is part of the language spec, is not honored when assigning callable properties to WorkflowScript ({{this}}).

          Fred Spieler added a comment -

          It seems that this is by design of restricted sandbox.

          Fred Spieler added a comment - It seems that this is by design of restricted sandbox.
          Fred Spieler made changes -
          Resolution New: Not A Defect [ 7 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

          Fred Spieler added a comment -

          Sorry, on second thought, I believe this is still a bug; if it's possible to overwrite WorkflowScript variables in restricted sandbox it should be fine to make the callable syntax functional.

          I'm clearly on the fence between bug and feature, but leaning towards bug.

          Fred Spieler added a comment - Sorry, on second thought, I believe this is still a bug; if it's possible to overwrite WorkflowScript variables in restricted sandbox it should be fine to make the callable syntax functional. I'm clearly on the fence between bug and feature, but leaning towards bug.
          Fred Spieler made changes -
          Resolution Original: Not A Defect [ 7 ]
          Status Original: Resolved [ 5 ] New: Reopened [ 4 ]

            abayer Andrew Bayer
            fspieler_bloomberg Fred Spieler
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: