jenkinsci / jenkinsci/workflow-multibranch-plugin

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

Open
#474 3 comments 0 reactions 0 assignees View on GitHub
component:workflow-multibranch-plugin imported-jira-issue priority:major resolution:unresolved
Dominant language
Java
Stars
87
Forks
131
PR merge metrics
No merged PRs in 30d

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.

---
Originally reported by jglick, imported from: Abort builds with untrusted Jenkinsfile, but only given passive cause


  • assignee: jglick
  • status: In Review
  • priority: Major
  • component(s): workflow-multibranch-plugin
  • resolution: Unresolved
  • votes: 0
  • watchers: 5
  • imported: 20251212-090250

Raw content of original issue

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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.