We are affected by both of those issues:

1. The whitelist problem
2. The import problem

The whitelist problem is fairly annoying because we run Job DSL from the Bitbucket Branch Source Plugin and this means every changes we make is going to require a whitelist change. Any thoughts on how to deal with this?

mkobit I think you are just missing the Authorize Project plugin settings, as described in https://github.com/jenkinsci/job-dsl-plugin/wiki/Script-Security

My problem is that importing classes doesn't work even if I run the job as an admin user (ERROR: script not yet approved for use is not happening then)

Thanks jbochenski, I'll have to dive into this today to see if there is a workaround for us.

I don't believe that it will solve our issues now, but maybe it will help.

Our "seed job" is automated and ran in a Jenkinsfile, and that will update the jobs on many other folders.

node {
  checkout scm
  timestamps {
    stage('Validate Jobs') {
      sh './gradlew build'
    }
    if (env.BRANCH_NAME == 'master') {
      stage('Process Job DSLs') {
        jobDsl(
          additionalClasspath: 'build/classes/main',
          failOnMissingPlugin: true,
          removedJobAction: 'DISABLE',
          removedViewAction: 'DELETE',
          targets: 'jobs/**/*.groovy'
        )
      }
    }
  }
}

Where one of our job files might look like

final rootFolder = folder('bitbucket_projects') {
  description('A 1:1 mapping of projects in Bitbucket to Jenkins')
  displayName('Bitbucket Projects')
}

organizationFolder("${rootFolder.name}/proj") {
  description('Bitbucket Branch Source for the PROJ project on Bitbucket Server')
  organizations {
    bitbucketSCMNavigator {
      autoRegisterHooks(true)
      bitbucketServerUrl('https://bitbucket.internal-corp.com')
      checkoutCredentialsId('checkout-creds-id')
      credentialsId('scan-creds-id')
      pattern('.*')
      repoOwner('PROJ')
      sshPort(7999)
    }
  }
  // Other configuration for organization folder
}

// Other folders

Users of this Jenkins instance will add and self-service their jobs into this job DSL definition for which our team would approve, and then the changes would automatically be applied.

Now, we can't do this in an entirely automated fashion because of these new additions of script security.

It seems like we have a couple possible options:

• Use the Authorize Project Plugin and hope we can configure it for organization folders
• Create an "seed job" and remove our automated pipeline job that needs to be manually triggered to run the job DSL
• Create a job that automatically runs using the Authorize Project Plugin

These seem entirely undesirable compared to our previous nearly full autonomous solution. We generally avoid installing additional plugins because they very frequently break and cause problems. Another reason is automating the configuration of these jobs' Authorization is not supported with the Job DSL (see JENKINS-29630) which makes it even more difficult to automate all of this stuff.

It doesn't seem like the jobDsl step now in Jenkins Pipeline jobs with or without sandbox, presumably because the pipeline is already running in a sandbox.

This is not a bug, this is a consequence of fixing the security vulnerabilities as mentioned in https://jenkins.io/security/advisory/2017-04-10/.

Imported code is neither executed in the script security sandbox nor checked for approval by an administrator. Anyone with permission to modify the code will effectively gain administrative privileges in Jenkins. To fix that problem, the classpath is not extended by the "Additional classpath" or the script directory. And thus importing code is not possible when script security for Job DSL is enabled.

As mentioned in the Migration docs, there is a switch to restore the old behavior. But be careful with that.

Please move the discussion to the mailing list because this is interesting for a wider audience. I'm sure we can come up with a way to allow imports, but in a secure way.