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

GitHub manages hooks even when it has not been configured to do it

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • github-plugin
    • None

      Jenkins GitHub plugin requires a user with administration access to manage hooks:

      "There is no credentials with admin access to manage hooks on GitHubRepositoryName[host=example.org,username=username,repository=repository]"

      Such approach does not match our security guidelines, so we manage all hooks manually (from GitHub UI). Unfortunately, Jenkins still tries to manage webhooks even when we didn't ask to do it. Our servers list is empty:

      I searched for any option which will allow disable this behavior but I didn't find anything. This is the configuration of SCM for our projects:

      I believe it is a bug because Jenkins shouldn't do stuff, when we don't configure it. If this behavior is expected, then this ticket should be changed to a feature:

      Allow disabling managing webhooks when no GitHub server is configured

          [JENKINS-60901] GitHub manages hooks even when it has not been configured to do it

          Jim Klimov added a comment - - edited

          This annoys me too, so finally got to try making a fix: https://github.com/jenkinsci/github-plugin/pull/226

          In our use-case, there are a lot of stack traces (probably the majority of what the jenkins instance logs) while there is no credential set up AND the "Manage hooks" is unchecked. So it is supposed to not try managing, somewhat intentionally (our Jenkins is inside corporate perimeter, Github can't access it anyway).

          Note that according to help message for the "Manage Hooks" checkbox, there may be other places in code where it would check for credentials:

          > Will this configuration be used to manage credentials for repositories where it
          > has admin rights? If unchecked, this credentials still can be used to
          > manipulate commit statuses, but will be ignored to manage hooks.

          But the noisy (and in our case pointless) error message is only associated with register/unregister activity.

          Jim Klimov added a comment - - edited This annoys me too, so finally got to try making a fix: https://github.com/jenkinsci/github-plugin/pull/226 In our use-case, there are a lot of stack traces (probably the majority of what the jenkins instance logs) while there is no credential set up AND the "Manage hooks" is unchecked. So it is supposed to not try managing, somewhat intentionally (our Jenkins is inside corporate perimeter, Github can't access it anyway). Note that according to help message for the "Manage Hooks" checkbox, there may be other places in code where it would check for credentials: > Will this configuration be used to manage credentials for repositories where it > has admin rights? If unchecked, this credentials still can be used to > manipulate commit statuses, but will be ignored to manage hooks. But the noisy (and in our case pointless) error message is only associated with register/unregister activity.

          Jesse Glick added a comment -

          See also JENKINS-49332.

          I would suggest just removing the functionality to manage hooks from Jenkins, or at least make it opt-in. A reasonable security expectation is that Jenkins not have this permission. Note also that when you create a GitHub App (JENKINS-57351), it comes with its own webhook, so there is nothing to manage.

          Jesse Glick added a comment - See also JENKINS-49332 . I would suggest just removing the functionality to manage hooks from Jenkins, or at least make it opt-in. A reasonable security expectation is that Jenkins not have this permission. Note also that when you create a GitHub App ( JENKINS-57351 ), it comes with its own webhook, so there is nothing to manage.

            lanwen Kirill Merkushev
            agabrys Adam Gabryś
            Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: