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

Abort builds with untrusted Jenkinsfile, but only given passive cause

      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.

          [JENKINS-46795] Abort builds with untrusted Jenkinsfile, but only given passive cause

          Jesse Glick created issue -
          Jesse Glick made changes -
          Link New: This issue relates to JENKINS-45970 [ JENKINS-45970 ]
          Jesse Glick made changes -
          Assignee New: Jesse Glick [ jglick ]
          Jesse Glick made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Jesse Glick made changes -
          Component/s New: workflow-multibranch-plugin [ 21465 ]
          Component/s Original: github-branch-source-plugin [ 20858 ]
          Jesse Glick made changes -
          Remote Link New: This issue links to "workflow-multibranch-plugin #220 (Web Link)" [ 28399 ]
          Jesse Glick made changes -
          Status Original: In Progress [ 3 ] New: In Review [ 10005 ]
          Jesse Glick made changes -
          Description Original: 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.
          New: 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.
          Jesse Glick made changes -
          Summary Original: Trust PR revisions when approved New: Abort builds with untrusted Jenkinsfile, but only given passive cause
          Jesse Glick made changes -
          Description Original: 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.
          New: 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}}.
          Jesse Glick made changes -
          Link New: This issue relates to JENKINS-53752 [ JENKINS-53752 ]

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

              Created:
              Updated: