Details
-
New Feature
-
Status: Reopened (View Workflow)
-
Major
-
Resolution: Unresolved
Description
The plugin currently has no way to block untrusted users from making a PR from a fork and having this PR built by Jenkins. The GitHub Pull Request Builder does have this feature which is very useful for open source projects to protect the build system from malicious changes. The documentation on the GitHub Pull Request Builder wiki page says to move from the GHPRB plugin to the GitHub Branch source plugin which causes the user to lose this extremely useful functionality.
Attachments
Issue Links
- is duplicated by
-
JENKINS-55778 Github branch source plugin builds untrusted builds during scan
-
- Resolved
-
- relates to
-
-
- In Review
-
-
-
- Open
-
- links to
Activity
Right, which is why you must not run a Maven command inside a withCredentials block unless you are on a known (origin) branch.
jglick We understood the risk of auto-building a fork PR but trusted the Jenkins GitHub Branch Source Plugin to do what it said when we set Trust to "From users with Admin or Write permission"...that was our mistake. I am appalled by the fact that this issue is 4+ years old and no one seems to care.
Robert Patrick
added a comment - - edited jglick We understood the risk of auto-building a fork PR but trusted the Jenkins GitHub Branch Source Plugin to do what it said when we set Trust to "From users with Admin or Write permission"...that was our mistake. I am appalled by the fact that this issue is 4+ years old and no one seems to care. 
Brian J Murrell
added a comment - To be frank, we were pretty shocked also to find that PRs were not being blocked from untrusted sources amongst all of this, particularly given the screenshot in https://issues.jenkins.io/browse/JENKINS-53752?focusedCommentId=371866&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-371866.
We just ended up not allowing anything from forks. Our users are unhappy about that. Or repo has nearly a thousand branches now because we can only run PRs opened in our organization. The whole thing is a mess.
Our path forward is probably going to be to trigger Jenkins jobs from GitHub Actions since GitHub Actions has some at least half-way sane security settings for when PRs can run actions and when they cannot. No offence to anyone, but we simply cannot trust Jenkins in this regard any more.
Brian J Murrell
added a comment - To be frank, we were pretty shocked also to find that PRs were not being blocked from untrusted sources amongst all of this, particularly given the screenshot in https://issues.jenkins.io/browse/JENKINS-53752?focusedCommentId=371866&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-371866 .
We just ended up not allowing anything from forks. Our users are unhappy about that. Or repo has nearly a thousand branches now because we can only run PRs opened in our organization. The whole thing is a mess.
Our path forward is probably going to be to trigger Jenkins jobs from GitHub Actions since GitHub Actions has some at least half-way sane security settings for when PRs can run actions and when they cannot. No offence to anyone, but we simply cannot trust Jenkins in this regard any more. Robert Patrick
added a comment - I think Jenkins is starting to show its age. When CloudBees first got a involved, I was hopeful that the gaps and quality issues would improve and, for awhile, I think that they did. However, right now, it feels as bad as it did pre-CloudBees. I would love to help but it feels like the entire project is suffering from a lack of leadership. 😞
Robert Patrick
added a comment - I think Jenkins is starting to show its age. When CloudBees first got a involved, I was hopeful that the gaps and quality issues would improve and, for awhile, I think that they did. However, right now, it feels as bad as it did pre-CloudBees. I would love to help but it feels like the entire project is suffering from a lack of leadership. 😞 
You aren’t thinking this through. Suppose, for example, you are running a Maven command within a withCredentials block…same for running Make, ant, etc. change the build file being run and now you can grab the environment variables in any rogue script…