Skip to content

Mercury is now a GitHub secret scanning partner

GitHub secret scanning protects users by searching repositories for known types of secrets such as tokens and private keys. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with Mercury to scan for their license keys and help secure our mutual users on public repositories. Mercury tokens allow users to automate your banking needs through their API. GitHub will forward tokens found in public repositories to Mercury, who will then revoke them, keeping your account safe. Read more information about Mercury tokens.

All users can scan for and block Mercury tokens from entering their public repositories for free with push protection. GitHub Advanced Security customers can also scan for and block Mercury tokens in their private repositories.

Migrate tag protections to repository rules

We’ve now made migrating existing tag protection rules into repository rules easy. With a few clicks, you can take multiple tag protection rules and turn them into a single ruleset or turn each rule into corresponding rulesets for more granular control.

GIF of importing tag protection rules to repo rules.

Tag protection rules control who can create, update, and delete tags. Moving your tag protections to repository rules allows you to require status checks, deployments to pass, and signed commits. You also get the rest of the repository rules power, with configurable enforcement status, bypass lists, and flexible targeting.

For GitHub Enterprise Cloud customers, you can pair metadata restrictions with your tag protection to manage commit messages and control the names of your tags. 

Click here to learn more. If you have feedback, please share and let us know in our community discussion.

See more

Rate limits for /rate_limit REST API endpoint

Up until recently, the /rate_limit REST API endpoint was not covered by the API's rate limit. While this allowed API consumers to fetch rate limit information whenever they wanted, it was also a potential vector for abuse.

With that in mind, the /rate_limit endpoint is now covered by rate limits. Requests to the endpoint will not consume the primary rate limit quotas for the authenticated user. However, making a very high number of requests to the endpoint in a short period of time will trigger the secondary rate limits. Please follow the guidelines on avoiding the limits and what to do if you do hit them.

These limits are not intended to cause friction for any normal usage of the API. Rather, their aim is to prevent abusive patterns. If you run into any problems with these limits for the /rate_limit endpoint, please contact GitHub Support.

See more
View all changes