jenkinsgithubjenkins-plugins

How do you specify additional trusted files with the Jenkins Github Branch Source plugin?


I've created a Jenkins Multibranch Pipeline with the GitHub Branch Source plugin. The Jenkinsfile essentially just calls a Cake Build script (build.ps1, build.cake) that contains all the build/deploy logic. This allows me to move to another CI service easily.

Unfortunately, I cannot seem to figure out how to add my Cake Build scripts as a trusted file so that PR's from forks will pull the files from the source repo instead. The Trust setting of the Discover pull requests from forks behavior seems to indicate that there can be other trusted files besides Jenkinsfile:

Nobody

Pull requests from forks will all be treated as untrusted. This means that where Jenkins requires a trusted file (e.g. Jenkinsfile) the contents of that file will be retrieved from the target branch on the origin repository and not from the pull request branch on the fork repository.

However, I cannot seem to find any documentation on adding other trusted files. The primary reason for this is to prevent a PR from a fork from accessing credentials from the Cake script. They wouldn't be able to change Jenkinsfile, but they could still change the Cake script to expose the credentials.

Is it actually possible to add other trusted files?


Solution

  • I had a similar situation with a multi-branch pipeline for Gitea, not GitHub.

    The solution seems to be the readTrusted task. Call it for every file that should not be able to be modified from the trusted base-version and the build will fail.

    See https://www.jenkins.io/doc/pipeline/steps/workflow-multibranch/#readtrusted-read-trusted-file-from-scm which specifies:

    From a multibranch Pipeline project, reads a file from the associated SCM and returns its contents. Unlike the readFile step, no workspace is required. If the associated branch is not trusted, yet the file has been modified from its trusted version, an error is thrown. Thus this step is useful for loading scripts or other files which might otherwise be used to run malicious commands. Like checkout scm, as a convenience it may also be used from a standalone project configured with Pipeline from SCM, in which case there is no security aspect.