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

Abort builds with untrusted Jenkinsfile, but only given passive cause

    XMLWordPrintable

Details

    Description

      Currently ForkPullRequestDiscoveryTrait.TrustPermission returns false for PRs from authors without write permission. But this is annoying as it means that there is no good way to, say, contribute a Jenkinsfile to someone else's repository in a pull request—the builds will not run your code, which is safe, but then the maintainer cannot tell whether the script is good without either merging the PR (and potentially causing build breakages on other unrelated PRs), or filing their own PR which simply wraps yours.

      It should override checkTrusted(GitHubSCMSourceRequest, PullRequestSCMRevision) to check the GitHub API to see if the current revision has been approved by a maintainer. If so, we can presume it is safe to run.

      Revised proposal: ignore the trust level of the PR if the build is being triggered explicitly, for example Build Now inside Jenkins or via Re-run on a check. For builds triggered passively by the SCM commit, continue to pay attention to the trust level; but halt the build for transparency, rather than the current behavior of proceeding but with the trunk Jenkinsfile.

      Attachments

        Issue Links

          Activity

            NOTE: This is left as an exercise for an extension plugin, not to be implemented in the core github branch source plugin.

            stephenconnolly Stephen Connolly added a comment - NOTE: This is left as an exercise for an extension plugin, not to be implemented in the core github branch source plugin.
            jglick Jesse Glick added a comment -

            As per https://github.com/jenkinsci/workflow-multibranch-plugin/pull/69#issuecomment-376697899 currently we proceed with the build even though the proposed Jenkinsfile is not actually being tested, which is not good. I think it would better to fail the build (with NOT_BUILT status) but then make it easy for someone with either build permission in Jenkins, or write permission to the repository, to proceed. The former could be handled by suppressing the trust check when built via UserIdCause; the latter when via CheckRunGHEventSubscriber.GitHubChecksRerunActionCause. Perhaps we could just amend the trust behavior to apply only when the build was triggered by a branch indexing or SCM event cause?

            jglick Jesse Glick added a comment - As per https://github.com/jenkinsci/workflow-multibranch-plugin/pull/69#issuecomment-376697899 currently we proceed with the build even though the proposed Jenkinsfile is not actually being tested, which is not good. I think it would better to fail the build (with NOT_BUILT status) but then make it easy for someone with either build permission in Jenkins, or write permission to the repository, to proceed. The former could be handled by suppressing the trust check when built via UserIdCause ; the latter when via CheckRunGHEventSubscriber.GitHubChecksRerunActionCause . Perhaps we could just amend the trust behavior to apply only when the build was triggered by a branch indexing or SCM event cause?

            People

              jglick Jesse Glick
              jglick Jesse Glick
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated: