As a proactive measure to protect Github.com availability, GitHub Apps that attempt to create high-complexity scoped installation tokens will receive failures if they would individually reference too many repositories. At the time of release, no GitHub App is above these limits – the limit is approximately 8 times higher than what any app is consuming. See below for details on how complexity is calculated.
Scoped tokens allow a GitHub App to create an installation token that has just a subset of the privileges that the app has within an organization – both a reduced set of repositories, as well as permissions.
In this way, an application with many permissions and access to many repositories can still safely request a token that’s good for just the access that’s currently required, a useful least-privilege feature.
When requesting a scoped token, applications can indicate both the permissions and repositories that are desired. Both parameters are optional, and if either is omitted the full corresponding access will be given to the token, either all granted permissions or all accessible repositories.
The first limit being added is when the repositories are included in the token request – now, no more than 500 individual repositories can be listed.
The second limit is if the repositories are not listed but permissions are, and the application is installed on some repositories in the organization – as in, it has not been explicitly granted access to all repositories in the organization.
In that case, the limit is based on the number of permissions being requested and the number of repositories the application has access to. If the complexity limit is exceeded, the application will recieve an error: Too many repositories for installation, and provides the maximum number of repositories the application can have access to in order to succeed, as well as other options to reduce the complexity of your token, which are provided here as well.
To reduce the complexity of your token request, you can do one of the following:
1. Reduce the number of repositories that the application has access to in the organization.
2. Reduce the number of permissions requested for the token.
3. Set the application to have access to “all” of the organization’s repositories.
4. Not request a scoped token at all, and instead request a standard installation token.
Any of these options will reduce the complexity of the token and allow the application to fetch tokens for that organization once again.
To learn more about GitHub App scoped token issuance and installation, see our documentation:
CodeQL 2.16.2 is now available to users of GitHub code scanning on github.com, and all new functionality will also be included in GHES 3.13. Users of GHES 3.12 or older can upgrade their CodeQL version.
Important changes in this release include:
We added two new Java / Android queries (java/android/sensitive-text and java/android/sensitive-notification) to detect sensitive data exposure via text fields and notifications.
Secret scanning is extending validity check support to Mailgun (mailgun_api_key) and Mailchimp (mailchimp_api_key) API keys.
Validity checks indicate if the leaked credentials are active and could still be exploited. If you’ve previously enabled validation checks for a given repository, GitHub will now automatically verify validity for alerts on supported token types.
Validity checks are available for repositories with GitHub Advanced Security on Enterprise Cloud. You can enable the feature at both organization and repository levels from the “Code security and analysis” settings page by checking the option to “automatically verify if a secret is valid by sending to the relevant partner.”