We would like people who login to have scopes on the form: assume:repo:github.com/<organization>/<repository> However, people have thousands of repositories on github, and temporary credentials as issued by taskcluster-login can't be larger than 8kb, as they must be embedded in HTTP headers. HTTP header size is limited by heroku, but really 8kb is a sane limit. To work around this, I propose the following: for each team on github we create a role: github-team:<organization>/<team> with scopes: assume:repo:github.com/<organization>/<repository> for each repository that the team has write access to. (maybe we distinguish between read/write/admin later) I propose that taskcluster-github implements the logic that synchronizes this every 24 hours. Further more, taskcluster-github can use the github organization hooks to setup a webhook to be notified whenever: - a team is added/removed, - a member is added/removed from a team, or, - a team is granted/revoked access to a repository. (see https://developer.github.com/v3/activity/events/types/) Further more, taskcluster-github should expose an API end-point that given a github username returns the list of <organization>/<team>. This end-point should be used by taskcluster-login to grant scopes once people have logged-in with github. --- Limitations: 1) This won't support the use-case where people are added to a specific repository, instead of being added to a team that has access to the repository. This seems like an acceptable limitation. Though it forces people to use teams and organizations rather than personal repositories. 2) People who are member of a lot of github teams could still experience that the temporary credentials returned by taskcluster-login are too big. In practice this probably won't be many people.

To mitigate (1), perhaps we can give people assume:repo:github.com/<username>/*

(2) is "kind of a big deal". Those few people will probably be the most prolific devs, and they will be structurally locked out of TaskCluster.

Bug 1330761 should remove concerns about temp cred sizes. In fact, we discussed this yesterday, and decided to just create clients with `assume:repo:github.com:..` for every repo the user has write permission on. In other words, not doing the team synchronization in comment 0. We could optimize this a little by checking the set of roles and only include access to a repo in the client if there's a role defined for it.

Can we close this now that Bug 1427866 is resolved?

I think we still need to figure out how to do this, but that bug gets us quite a bit closer.

No, we still have to issue scope for controlling repo roles, etc. to github users when they login.