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

github is deprecating basic authentication using password

      You recently used a password to access an endpoint through the GitHub API using okhttp/2.7.5. We will deprecate basic authentication using password to this endpoint soon:

      https://api.github.com/repositories/155774655

      We recommend using a personal access token (PAT) with the appropriate scope to access this endpoint instead. Visit https://github.com/settings/tokens for more information.

      This might be just something that admins need to deal w/, but it would be helpful if there was a migration page explaining what to do from the jenkins side.

      (it isn't particularly obvious to me)

          [JENKINS-60480] github is deprecating basic authentication using password

          Josh Soref created issue -
          Carlos Jenkins made changes -
          Attachment New: image-2019-12-18-16-27-49-854.png [ 49821 ]
          Carlos Jenkins made changes -
          Attachment New: image-2019-12-18-16-29-44-602.png [ 49822 ]

          Hi,

          I got the same email for two of my Jenkins deployments. That's how I got here

          In particular the GitHub Branch Source Plugin only supports using username and password, so the functionality provided by that plugin may break when the deprecation takes place.

          Current code of the GitHub Branch Source Plugin shows:

          https://github.com/jenkinsci/github-branch-source-plugin/blob/23c8a226eef074da7b87bc4b629f6a9f75bf4766/src/main/java/org/jenkinsci/plugins/github_branch_source/Connector.java#L339

           

          Looking at what PyGitHub does (project that I use with tokens to automate some things):

          https://github.com/PyGithub/PyGithub/blob/baddb7193f24fc988def1ead53876024be6066e0/github/Requester.py#L278

           

           

          It looks like GitHub supports passing token in the Authorization header. So, in theory, the GitHub Branch Source Plugin could use a "Secret Text" type secret with the token an pass it down in the Authorization header.

          Its interesting to note that the GitHub Plugin already supports (actually only supports) using access tokens. So, in my Jenkins deployment I have to have two secrets:

          • A "Username with password" type for GitHub Branch Source Plugin, and
          • A "Secret text" for the GitHub plugin.

           

           

          Carlos Jenkins added a comment - Hi, I got the same email for two of my Jenkins deployments. That's how I got here In particular the GitHub Branch Source Plugin only supports using username and password, so the functionality provided by that plugin may break when the deprecation takes place. Current code of the GitHub Branch Source Plugin shows: https://github.com/jenkinsci/github-branch-source-plugin/blob/23c8a226eef074da7b87bc4b629f6a9f75bf4766/src/main/java/org/jenkinsci/plugins/github_branch_source/Connector.java#L339   Looking at what PyGitHub does (project that I use with tokens to automate some things): https://github.com/PyGithub/PyGithub/blob/baddb7193f24fc988def1ead53876024be6066e0/github/Requester.py#L278     It looks like GitHub supports passing token in the Authorization header. So, in theory, the GitHub Branch Source Plugin could use a "Secret Text" type secret with the token an pass it down in the Authorization header. Its interesting to note that the GitHub Plugin already supports (actually only supports) using access tokens. So, in my Jenkins deployment I have to have two secrets: A "Username with password" type for GitHub Branch Source Plugin, and A "Secret text" for the GitHub plugin.    

          Mark Waite added a comment -

          Isn't that message saying that you can continue to use basic auth so long as instead of using your actual password you use a personal access token. Generate a personal access token from the GitHub "Settings" page and store that personal access token in the Jenkins username / password credential as the password. Place your username as the username. Check that it works. It has been working that way for me.

          Mark Waite added a comment - Isn't that message saying that you can continue to use basic auth so long as instead of using your actual password you use a personal access token. Generate a personal access token from the GitHub "Settings" page and store that personal access token in the Jenkins username / password credential as the password. Place your username as the username. Check that it works. It has been working that way for me.

          Josh Soref added a comment -

          markewaite: Do you know what permissions we should give it in https://github.com/settings/tokens/new?

          My ticket isn't claiming that work necessarily needs to be done in the plugin, just that a "what to do" should be published. (Although, probably it's best for the plugin to just guide people through the process since it seems like it'd be pretty easy for it to do that and remember "this token is good" or something.)

          Josh Soref added a comment - markewaite : Do you know what permissions we should give it in  https://github.com/settings/tokens/new ? My ticket isn't claiming that work necessarily needs to be done in the plugin, just that a "what to do" should be published. (Although, probably it's best for the plugin to just guide people through the process since it seems like it'd be pretty easy for it to do that and remember "this token is good" or something.)

          Mark Waite added a comment - - edited

          Repository read should be enough jsoref, unless your job is pushing changes back to the server.

          I think we should document the credential choices as part of a larger picture of ways to use Jenkins most effectively with git. When using GitHub, prefer username and a personal access tokens rather than username and password. Same advice would apply to Bitbucket, Gitlab, Gitea, Team Foundation Server, and more.

          Mark Waite added a comment - - edited Repository read should be enough jsoref , unless your job is pushing changes back to the server. I think we should document the credential choices as part of a larger picture of ways to use Jenkins most effectively with git. When using GitHub, prefer username and a personal access tokens rather than username and password. Same advice would apply to Bitbucket, Gitlab, Gitea, Team Foundation Server, and more.

          Josh Soref added a comment -

          Also, a quick look at my jenkins /credentials/store/system/domain/_/ shows that the account currently has a token with repo which was Last used within the last week according to github, and yet, I'm still getting warnings.

          Josh Soref added a comment - Also, a quick look at my jenkins /credentials/store/system/domain/_/  shows that the account currently has a token with repo which was Last used within the last week according to github, and yet, I'm still getting warnings.

          Mark Waite added a comment -

          Maybe you're using the actual password from another location or through a different credential? I've not received any warnings from GitHub for my https repository access. I'll continue watching my mailbox in case it arrives.

          Mark Waite added a comment - Maybe you're using the actual password from another location or through a different credential? I've not received any warnings from GitHub for my https repository access. I'll continue watching my mailbox in case it arrives.

          Josh Soref added a comment - - edited

          Ok, for us, there were apparently two items. I've switched things over to the other one. Hopefully that will make the alert go away.

          But this experience was painful.

          One thing that would help immensely is the ability to search for credentials whose password matches an entered value. Expected results should only include passwords the searching user is allowed to use. Had I been able to do that, I could have quickly identified the problem.

          Fwiw, the best I've managed is:

          admin:org, admin:public_key, admin:repo_hook, read:user, repo 

          We had credentials of:

          repo 
          admin:repo_hook, repo 

          But they weren't sufficient for us.

          Josh Soref added a comment - - edited Ok, for us, there were apparently two items. I've switched things over to the other one. Hopefully that will make the alert go away. But this experience was painful. One thing that would help immensely is the ability to search for credentials whose password matches an entered value. Expected results should only include passwords the searching user is allowed to use. Had I been able to do that, I could have quickly identified the problem. Fwiw, the best I've managed is: admin:org, admin:public_key, admin:repo_hook, read:user, repo We had credentials of: repo admin:repo_hook, repo But they weren't sufficient for us.

            lanwen Kirill Merkushev
            jsoref Josh Soref
            Votes:
            4 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: