Make GitHub scopes configurable #91

bradrydzewski opened this Issue Feb 18, 2014 · 8 comments


None yet

4 participants


cc @suguru

this was brought up in issue #75

when GitHub enterprise is run in private mode it prevents using git:// to clone public projects. This means every repository should be treated as a private repository -- using the git@ url and adding the ssh deploy key.


You still can use http to clone repos when GH:E is in private mode. It would only require an oauth token with the right privileges. Using oauth tokens is easier to manage, since you don't have to add the deploy key to every repo, and probably more secure, since revoking access only requires you to remove the grant for the token in your organization.


yes, we can definitely alter our approach to use the github oauth token. In this case I think we'll want to generate a .netrc file to store the credentials in the container. This would allow an individual to clone multiple private repositories as part of their build script without embedding credentials in the .drone.yml file.

we need to rework our git logic anyway to support caching:
#147 (comment)

@bradrydzewski bradrydzewski changed the title from GitHub Enterprise & Private Mode to Use GitHub Token to clone private repos instead of SSH Key Mar 23, 2014

I wanted to document a conversation I'm having on our mailing list. It looks like GitHub now offers admin:repo_hook which means we can probably re-think our scopes and require much less invasive permissions.

I think we should use these scopes:

admin:repo_hook  -> this allows us to write hooks to the repo  
repo:status      -> this allows us to write the build status to github
user:email       -> this allows us to retrieve the user details, including the email

We wouldn't be able to add an SSH key to the repository with the above scopes, however, this would be resolved (as mentioned above) by using the OAuth token to clone the repository, using the https address:

git clone https://<token>

I believe the .netrc will still be very important. We'll need to ensure we can clone private dependencies (when using things like go get, for example). We'll need to account for this when generating our build container.

We'll also need to add the username/password to the build.Builder.Repo somewhere in the queue (I think).

I'm modifying the title of this issue to reflect the revised goal and solution

@bradrydzewski bradrydzewski changed the title from Use GitHub Token to clone private repos instead of SSH Key to Alter GitHub scopes to require less permissions Apr 11, 2014

Maybe I spoke too soon... It looks like to clone a repository we still need to request the repo scope, which requires read/write access to a repository.

I see GitHub has been doing a lot of work to add more fine-grained scopes. @calavera are there plans to create a scope that can clone a repository without requiring write access? something like repo:read?


Yes, the lack of a repo:read scope was the main roadblock I ran into when I was investigating this. Having that scope would be very useful.
AFAIK, the only way right now to clone a private repository without also requiring write access was to create a "machine user" with read-only permissions to the repository, which was the workaround I suggested on the mailing list. Unfortunately this user cannot create commit status and repo hooks on the organization's private repos.


Yep, the GitHub team has clearly been putting a lot of effort into security and scopes, which is awesome. I wouldn't be surprised if repo:read was on their roadmap. Hopefully @calavera has some inside information he can share :)


Would it be possible to let the user choose public_repo instead of only repo? I don't need for my private projects.

@bradrydzewski bradrydzewski added this to the v0.4.1 milestone Aug 18, 2015
@bradrydzewski bradrydzewski changed the title from Alter GitHub scopes to require less permissions to Make GitHub scopes configurable Aug 18, 2015
@bradrydzewski bradrydzewski modified the milestone: Unplanned, v0.4.1 Oct 26, 2015

fixed by #1511

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment