[JIRA] (JENKINS-59016) GitHub branch source 2.5.5 & newer ignore domain limited credentials when scanning

13 views
Skip to first unread message

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 22, 2019, 3:31:02 PM10/22/19
to jenkinsc...@googlegroups.com
Mark Waite updated an issue
 
Jenkins / Bug JENKINS-59016
GitHub branch source 2.5.5 & newer ignore domain limited credentials when scanning
Change By: Mark Waite
Summary: GitHub branch source 2.5.5 & newer correctly ignore domain limited credentials when scanning
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 22, 2019, 3:33:05 PM10/22/19
to jenkinsc...@googlegroups.com
Mark Waite updated an issue
The GitHub branch source plugin uses the GitHub REST API to scan  remote repositories for changes.  I had incorrectly defined my GitHub credential in a credential domain that only included the {{github.com}} domain.  The GitHub branch source plugin allowed me to select that credential, but then would not use that credential because it was making the request to {{api.github.com}} rather than {{github.com}}.

My working credential domains had defined the domain as {{github.com,*.github.com}}.  That working definition matched {{api.github.com}}.

My incorrect credential domain was specified as only including {{github.com}}.  With that incorrect domain specificiation, the repository scan log would report:

{code}
Started
[Tue Aug 20 13:00:40 MDT 2019] Starting branch indexing...
13:00:40 Connecting to https://api.github.com with no credentials, anonymous access
{code}

Without the credentials, scanning of private repositories is not allowed and scanning of public repositories is limited by a much smaller value for the GitHub API rate limit.

||Version||Result||
||2.5.6||Credentials ignored if assigned incorrect domain|
||2.5.5||Credentials ignored if assigned incorrect domain|
||2.5.4|Credentials honored if assigned incorrect domain|
||2.5.3|Credentials honored if assigned incorrect domain|
||2.4.5|Credentials honored if assigned incorrect domain|
||2.3.6|Credentials honored if assigned incorrect domain|

Refer to the [JENKINS-59016 branch in my jenkins-bugs repo|https://github.com/MarkEWaite/jenkins-bugs/tree/JENKINS-59016] for the Jenkins Pipeline that I use to test this.  The jobs are run from inside a Docker image that I use which includes credentials used to access the repository.

Credential domains usually only control user interface visibility of the credential, not job internal visibility of the credential.  Beginning with GitHub branch source 2.5.5, the credential domain also controls job internal visibility of the credential.

jnord@cloudbees.com (JIRA)

unread,
Apr 28, 2020, 8:29:03 AM4/28/20
to jenkinsc...@googlegroups.com
James Nord commented on Bug JENKINS-59016
 
Re: GitHub branch source 2.5.5 & newer ignore domain limited credentials when scanning

this causes lots of confusion when the credential works for an organisation folder (scanning all of github) and then the scan of the actual repo does not and falls back to anonymous.

eg.

[Thu Mar 19 11:12:10 UTC 2020] Updating actions...
Looking up details of myghorg...
Organization URL: CloudBees
[Thu Mar 19 11:12:10 UTC 2020] Consulting GitHub Organization
11:12:10 Connecting to https://api.github.com using my-credential/****** (PAT token for GitHub)
11:12:10 Looking up repositories of organization myghorg
Ignoring wibble
Ignoring bar
Ignoring foo
...
ignoring silly-name
Proposing some-repo
11:13:21 GitHub API Usage: Current quota has 59 remaining (5 under budget). Next quota of 60 in 1 hr 0 min
11:13:22 Connecting to https://api.github.com with no credentials, anonymous access
ERROR: [Thu Mar 19 11:13:22 UTC 2020] Could not fetch sources from navigator org.jenkinsci.plugins.github_branch_source.GitHubSCMNavigator@7cf2c1ef

I beleive the scanning is done by the same plugin - which is why this is just confusing.

> Credential domains usually only control user interface visibility of the credential, not job internal visibility of the credential

that should never be the case, where it is it is a security issue in the plugins that do that - please file them if you know of this.
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
Atlassian logo

bitwiseman@gmail.com (JIRA)

unread,
Apr 28, 2020, 1:58:04 PM4/28/20
to jenkinsc...@googlegroups.com

> Credential domains usually only control user interface visibility of the credential, not job internal visibility of the credential

that should never be the case, where it is it is a security issue in the plugins that do that - please file them if you know of this.

Not according to the documentation: 

The use-case for credentials domains is to provide a way for the user to provide information about the services with which the credentials are expected to work.
Credential domains are intended to help select correct credentials for each services.

 
Credential domains are not intended to prevent credentials from being used against the wrong services.

 
In some cases, the domain requirements of a credential cannot be determined, such as when using a credentials parameter or when using a plugin that has not fully implemented the recommendations of the consumer guide.
 

In order to ensure that users can actually select the required credentials in these cases, the Credentials API needs to return credentials from all domains, which is why we use Excluding credentials from domains that do not match.
 

Because of the above: Credential domains are not intended to restrict access to credentials.

https://github.com/jenkinsci/credentials-plugin/blob/master/docs/user.adoc

 

 

jnord@cloudbees.com (JIRA)

unread,
Apr 28, 2020, 2:28:02 PM4/28/20
to jenkinsc...@googlegroups.com

> In some cases, the domain requirements of a credential cannot be determined, such as when using a credentials parameter or when using a plugin that has not fully implemented the recommendations of the consumer guide.

 

Yes - and not implementing the consumer guide correctly is a bug, credentials being security sensitive makes it a security bug.

bitwiseman@gmail.com (JIRA)

unread,
Apr 30, 2020, 10:57:03 PM4/30/20
to jenkinsc...@googlegroups.com

> Credential domains are not intended to prevent credentials from being used against the wrong services.

> Credential domains usually only control user interface visibility of the credential, not job internal visibility of the credential that should never be the case, where it is it is a security issue in the plugins that do that - please file them if you know of this.

Okay, so...
According to the documentation, since this plugin is refusing to use a credential that is in the wrong domain, it is a security issue.

Now what? Does this move into the SECURITY JIRA and get prioritized against other security issues?

bitwiseman@gmail.com (JIRA)

unread,
Apr 30, 2020, 11:01:02 PM4/30/20
to jenkinsc...@googlegroups.com
Liam Newman edited a comment on Bug JENKINS-59016
> Credential domains are not intended to prevent credentials from being used against the wrong services.

> Credential domains usually only control user interface visibility of the credential, not job internal visibility of the credential that should never be the case, where it is it is a security issue in the plugins that do that - please file them if you know of this.

Okay, so I get it . ..
According to the documentation, since
  
Since this plugin is refusing to use a credential that is in the wrong domain, it is a incorrect behavior related to credentials.  Thus a security issue.

Now what? Does this move into the SECURITY JIRA and get prioritized against other security issues?

jnord@cloudbees.com (JIRA)

unread,
May 1, 2020, 3:56:03 AM5/1/20
to jenkinsc...@googlegroups.com

Okay, I get it.


Since this plugin is refusing to use a credential that is in the wrong domain, it is a incorrect behavior related to credentials. Thus a security issue.

refusing to use a credential that is in the wrong domain is the correct behaviour.

knowingly using a credential that is in a domain that does not match is a security issue as it could lead to credential leaking.

if you know if a plugging that fits that please raise a security issue for discussion

 

bitwiseman@gmail.com (JIRA)

unread,
May 5, 2020, 7:17:03 PM5/5/20
to jenkinsc...@googlegroups.com

> refusing to use a credential that is in the wrong domain is the correct behaviour

So, this plugin is doing the right thing then?
What are you trying to say? That this isn't bug but correct behavior? I'm so confused.

jnord@cloudbees.com (JIRA)

unread,
May 5, 2020, 8:00:02 PM5/5/20
to jenkinsc...@googlegroups.com

read my first comment again and look closely at the log snippet.

 

The plugin is simultaneously correct and incorrect, Schroedinger would be proud.

When performing the org scan it is appearing to allow invalid credentials to be used.  when examining the individual repo that same credential is now (correctly?) not used.

given all calls should be to the same host (API.github.com in this case) there should be no reason why the credential is valid for one but not the other.

this behaviour  is at best confusing as heck.

 

 
Reply all
Reply to author
Forward
0 new messages