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

Builds from untrusted source on Branch Indexing

    Details

    • Similar Issues:

      Description

      Using the same configuration as is detailed in JENKINS-58618, I am also finding that PRs that should not be built because they are from untrusted sources will get built during the Branch Indexing:

      Checking pull request #814
       (not from a trusted source)
       'Jenkinsfile' found
       Met criteria
      Changes detected: PR-814 (null → [redacted])
      Connecting to https://api.github.com to check permissions of obtain list of [redacted] for [redacted]/[redacted]
      Loading trusted files from base branch master at [redacted] rather than [redacted]
      Scheduled build for branch: PR-814
      

      You can see that it was determined to be untrusted and reverted to the Jenkinsfile from the origin instead of the PR, but shouldn't the setting in:

      https://issues.jenkins-ci.org/secure/attachment/48061/image-2019-07-23-10-30-22-210.png

      mean that it's not even run at all?

        Attachments

          Activity

          Hide
          bitwiseman Liam Newman added a comment -

          Brian J Murrell 

          I agree this is a problem.  Tracking down where it is coming from is a bit more involved, partly because the basic-build-branch plugin currently often doesn't log output about what it observes.  This means that I can't really tell from this output what is going on - why it is choosing to build these PRs instead of rejecting them. 

          Have you tried setting Trusted to "Nobody" as suggested here:

          https://issues.jenkins-ci.org/browse/JENKINS-53752?focusedCommentId=373461&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-373461

          From what I see that results in the correct behavior, so for truly untrusted cases the filter seems to work:

           

          Checking pull request#10
          (not from a trusted source) ‘Jenkinsfile’ found Met criteria Changes detected: PR-10-head (badd9a4f697a55c573b4d4fbabb61870e8efa4ea → e9e963e7ebfd5a54874c8962a9108930edcbb421) Loading trusted files from base branch master at bc1bf622bedeb9a04debfa2236620eb0edac6dc6 rather than e9e963e7ebfd5a54874c8962a9108930edcbb421 No automatic build triggered for PR-10-head (not from a trusted source)

           

          You could then specific users to still build for.  

          To be clear, there is a bug here and it should be fixed, but it will take some work to isolate. 

           

           

          Show
          bitwiseman Liam Newman added a comment - Brian J Murrell   I agree this is a problem.  Tracking down where it is coming from is a bit more involved, partly because the basic-build-branch plugin currently often doesn't log output about what it observes.  This means that I can't really tell from this output what is going on - why it is choosing to build these PRs instead of rejecting them.  Have you tried setting Trusted to "Nobody" as suggested here: https://issues.jenkins-ci.org/browse/JENKINS-53752?focusedCommentId=373461&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-373461 From what I see that results in the correct behavior, so for truly untrusted cases the filter seems to work:   Checking pull request #10 (not from a trusted source) ‘Jenkinsfile’ found Met criteria Changes detected: PR-10-head (badd9a4f697a55c573b4d4fbabb61870e8efa4ea → e9e963e7ebfd5a54874c8962a9108930edcbb421) Loading trusted files from base branch master at bc1bf622bedeb9a04debfa2236620eb0edac6dc6 rather than e9e963e7ebfd5a54874c8962a9108930edcbb421 No automatic build triggered for PR-10-head (not from a trusted source)   You could then specific users to still build for.   To be clear, there is a bug here and it should be fixed, but it will take some work to isolate.     
          Hide
          brianjmurrell Brian J Murrell added a comment -

          Is it really appropriate to downgrade a security-impacting issue like this to Major?

          Have you tried setting Trusted to "Nobody" as suggested here:

          That's not the behaviour we are looking for though. We want members of the organisation to be able to push PRs from their own GitHub accounts (i.e. as opposed to using branches within the organisation) and have Jenkins build those.

          Show
          brianjmurrell Brian J Murrell added a comment - Is it really appropriate to downgrade a security-impacting issue like this to Major ? Have you tried setting Trusted to "Nobody" as suggested here: That's not the behaviour we are looking for though. We want members of the organisation to be able to push PRs from their own GitHub accounts (i.e. as opposed to using branches within the organisation) and have Jenkins build those.
          Hide
          bitwiseman Liam Newman added a comment -

          Fair enough, I've returned the priority to Critical. I'm not the owner/maintainer of this plugin, just effected by it. 

          For security issues like this, you should file an issue under the Jenkins Jira "SECURITY" project. That will likely get more attention that a general functionality issue. See https://jenkins.io/security/ for details.

          Show
          bitwiseman Liam Newman added a comment - Fair enough, I've returned the priority to Critical. I'm not the owner/maintainer of this plugin, just effected by it.  For security issues like this, you should file an issue under the Jenkins Jira "SECURITY" project. That will likely get more attention that a general functionality issue. See  https://jenkins.io/security/  for details.

            People

            • Assignee:
              Unassigned
              Reporter:
              brianjmurrell Brian J Murrell
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: