Changelog

Subscribe to all Changelog posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

→ ~ cd github-changelog
→ ~/github-changelog|main git log main
showing all changes successfully

General availability of granular access token on npm

Today we are making the granular access token feature on npm generally available.

Granular access token, allows you to:

  • Restrict token access to specific packages and/or scopes
  • Grant tokens access to specific organizations for org and user management
  • Set a token expiration date
  • Limit token access based on IP address ranges
  • Select between read and/or write access for the token

We recommend using granular access tokens with least privileges for automating your publishing and org management activities. You can allow your package to be published without 2FA using granular access tokens from your trusted CI/CD systems. Additionally, you can also configure your package to require 2FA when publishing from a local machine to defend against account hijacking.

Read more about creating a granular access token here.

See more

You can now use the “security extended” query suite in code scanning default setup with CodeQL

You can now enable the "security extended" query suite for repositories using code scanning default setup with CodeQL. This query suite can be selected during set up, or changed at any time by viewing and editing the CodeQL configuration.

Code scanning's default query suites have been carefully designed to ensure that they look for the security issues most relevant to developers, whilst also minimizing the occurrence of false positive results. However, if you and you developers are interested in seeing a wider range of alerts you can enable the security extended query suite. This suite includes the same queries as in the default query suite, plus:

  • extra queries with slightly lower severity and precision.
  • extra experimental queries.

If you enable the security extended suite you may see more CodeQL alerts in your repository and on pull requests. For more information, see "About code scanning alerts".

Code scanning default setup query suites

Code scanning default setup view configuration

Read more about code scanning default setup.

See more

Enable code scanning default setup with CodeQL at the organization level (public beta)

Enabling CodeQL analysis with code scanning default setup for eligible repositories in your organization is now as easy as a single click from the organization's settings page or a single API call.

Code scanning enable all default setup button on the organization's 'Settings' page

You can use code scanning default setup to enable CodeQL analysis for pull requests and pushes on eligible repositories without committing any workflow files. Currently, this feature is only available for repositories that use GitHub Actions and it supports analysis of JavaScript/TypeScript, Python and Ruby. We plan to add support for additional languages soon.

To help you identify which repositories are eligible for the "enable all" feature, two new security coverage filters have been added:

  • code-scanning-default-setup: returns a list of enabled, eligible or not eligible repositories
  • advanced-security: returns a list of repositories with GitHub Advanced Security enabled or not enabled

This feature has been released as a public beta on GitHub.com and will also be available as a public beta on GitHub Enterprise Server 3.9.

Learn more about configuring code scanning at scale using CodeQL and the "Enable or disable a security feature for an organization" REST API

Learn more about GitHub Advanced Security

See more

Secret scanning changes to how you opt in to notifications

We announced two weeks ago that we are changing how you receive notifications for secret scanning alerts. From today, those changes are in effect.

What action should I take?

If you are a repository administrator, organization owner, security manager, or user with read access to secret scanning alerts:

  • Watch your repositories of interest by choosing "All activity" or "Security alerts." This helps you choose what events GitHub will notify you about.
  • In your user notification settings, you must choose "Email" in the "Watching" section. This tells GitHub how to notify you. Secret scanning only supports email notifications at this time.

If you're a commit author:

As long as you are not ignoring the repository in your watch settings, commit authors always receive notifications for new secrets that are leaked. This means you receive a notification for any secret committed after an initial historical scan has run on the repository.

Learn more

See more

Code scanning shows more accurate and relevant alerts on pull requests

Code scanning is now using a new way of analysing and displaying alerts on pull requests. The change ensures code scanning only shows accurate and relevant alerts for the pull request.

Previously, code scanning presented all alerts unique to the pull request branch, even if they were unrelated to the code changes the pull request introduced. Now, the tool reports only alerts inside the lines of code that the pull request has changed, which makes it easier to fix these contextualised alerts in a timely manner.

code scanning on the slide-out enablement panel on the security coverage page

The complete list of code scanning alerts on the pull request branch can be seen on the Security tab of the repository.

code scanning on the slide-out enablement panel on the security coverage page

In addition, code scanning will no longer show fixed alerts on pull requests. Instead, you can check whether an alert has been fixed by your pull request on the Security tab of the repository by using search filters: pr:111 tool:CodeQL. If you fix an alert in the initial commit in the pull request, it will not be present on the PR branch.

This has shipped to GitHub.com and will be available in GitHub Enterprise Server 3.10.

Learn more about viewing an alert on your pull request.

Learn more about GitHub Advanced Security.

See more

SSH Certificate requirement update

The "Require SSH certificates" policy now allows GitHub apps to call Git APIs using a user-to-server token, bringing them up to parity with OAuth app support.

The SSH certificate requirement mandates that users in your organization call Git APIs using an SSH certificate issued by your organization, in place of their own SSH key or a PAT.
To support automation, it has an exception in place for OAuth apps and GitHub app server-to-server tokens, which allows applications you've approved to call Git APIs for your organization.
With this change, we are extending that exception to GitHub app user-to-server tokens, for when a user has signed into a GitHub app that's installed in your organization.

Screenshot of the SSH Certificate requirement checkbox

This change also applies when the enterprise-level setting requires SSH certificates across all organizations in the enterprise.

To learn more, see "Managing your organization's SSH certificate authorities" or "Managing SSH certificate authorities for your enterprise".

See more

Fixed bug that allowed removed users to retain access to the organization

GitHub Security was notified about an issue where users still had access to organizations after being removed. Our Security team investigated potential instances and determined there were occasional instances where users’ permissions were not fully removed when teams were deleted or they were part of a team when they were removed from the organization. While we investigated the root causes, which stemmed from background job and permissions issues, a manual fix has been implemented since October 20, 2022. We have addressed the underlying issues and the need for the previously implemented manual fix. We have also cleaned up any users that were not removed when they should have been. There is no further action that is required by any organization.

See more

Introducing the GitHub Markdown Helpers Public Beta

GitHub users write a lot of Markdown; so much so that we render 2 billion Markdown files everyday; at peak times, we're processing 1,300 Markdown files a second! Any opportunity we have to shave a few seconds off of the Markdown authoring experience on GitHub is time well-spent.

Introducing Markdown Helpers powered by Slash Commands

To use Markdown Helpers, simply type / on Issues, Pull Requests, or Discussion descriptions/comments and use the subsequent dialog to choose from a number of useful Markdown shortcuts.

Use shortcuts like /table to make Markdown tables a breeze, or /details to make selectively showing content to readers much easier than remembering the HTML formatting.

As part of our first release, we've included 6 out-of-the-box features which we hope will help teams author Markdown faster and with less context switching:

  • Code Block
    • Support for language-specific syntax highlighting
  • Details
    • Specify details that the reader can open and close on demand
  • Saved Replies
  • Table
    • Easily insert Markdown Tables
  • Templates
    • Easily populate your Repository's Issue or Pull Request templates directly from Slash Commands!
  • Tasklist
    • Easily insert a Tasklist
    • Note: Tasklists are currently in Private Beta, only users in organizations added to the Private Beta will see this option)

We'd love to hear from you!

Be sure to check out the official Slash Commands documentation for more details on the commands we're releasing today.

Anything we missed? Got an idea for a great Slash Commands feature?

Please leave us some feedback in our Feedback Discussion about how you'd like to use Slash Commands on GitHub.

See more

Adding the ability to close GitHub Discussions

GitHub Discussions now supports the ability to close a Discussion. Discussions can be closed for one of three reasons: Resolved, Outdated, or Duplicate. Closing a Discussion is much like closing an Issue or a Pull Request. Users can select a reason for closing in the dropdown. A screenshot of the dropdown is shown below:

Dropdown showing Close Discussion options

The reason for closing is visible to users in two places on the page.

First, in the icon at the top of the Discussion:

Icon at the top of Discussions showing that it is closed

Second, on the events timeline:

The event timeline showing a Discussion being closed

Besides the state of the Discussion being visible on the page, we're also now surfacing the state of a Discussion in search. We're adding three new filters:

is:<closed/opened>
filters out open/closed discussions

reason:<resolved/outdated/duplicate>
returns closed discussions that were closed with the provided reason

closed:<date>
returns discussions closed on a certain date. Supports < and > operators to get discussions closed before or after the date.

See more

Comment on files in a pull request (public beta)

Commenting directly on a file in a pull request (not just a specific line) is now available in public beta! 🎉

With this capability you can now comment on deleted, binary (including images), and renamed files in a pull request. You can also comment generally about a changed code file without having to attach the comment to a specific line.

How it works

To comment on any file in a pull request, click the Comment on this file button in the header of the file (next to the Viewed checkbox):
image

Comments on files appear in the Files Changed and Conversation tabs and can be replied to and resolved like regular review comments.
image

Tell us what you think

This feature is currently in public beta, with GitHub Mobile and API support coming soon.

Join the discussion and let us know what you think!

See more

Projects on GitHub Mobile is now generally available

Projects on GitHub Mobile

Projects on GitHub Mobile are now available for iOS and Android! Find the projects you're working on through a repository, organization, or from your user profile. You can also easily change views in a project to browse your issues and pull requests grouped and organized just as you like.

Custom fields and metadata, such as status, category, priority, and iteration, are displayed as an easy-to-read list within a project item. Simply tap on the list to edit the fields, or long-press on a project item for further actions like closing it or previewing its content.

Update your GitHub Mobile apps today from the Android Google Play or iOS App Store.

Read more about GitHub Mobile and send us your feedback to help us improve.

See more

Organization Audit Logs include IP addresses – Public Beta

GitHub organization owners can now opt-in to a public beta to display organization members' IP addresseses in audit logs events. When enabled, IP addresses will be displayed for all audit log events performed by organization members on organization assets other than public repositories, which will be treated differently due to privacy obligations.

The inclusion of IP addresses in audit logs helps software developers and administrators protect their systems and data from potential threats and improve their overall security posture by providing the source of an action or event within a system or network. This information is crucial for troubleshooting issues or investigating security incidents. IP addresses are often used in forensic investigations to trace the origin of cyberattacks, unauthorized access, or other malicious activities.

For additional information and instructions for enabling this feature, read about displaying IP addresses in the audit log for your organization.

See more

Changes to the code search API

We are preparing to bring powerful new code search capabilities to GitHub. As part of that effort, on April 10, 2023, we will make several changes to the code search API:

  • Code search rate limits will be separated from the rate limits for other search types. The separate code search category will have a rate limit of 10 requests per minute.
  • We are deprecating support for sorting code search results. Once these changes take effect, all code search results will be sorted by best match.
  • All code search API endpoints will require authentication. This change only affects repository scoped queries, because all other query types already require authentication.

To prepare for these changes, make sure your code handles rate limiting. And if you’re using code search to track changes or find security vulnerabilities in your codebase, consider using webhooks or GitHub Advanced Security.

These changes will take effect in 30 days, on April 10, 2023.

See more

Delete stale code scanning configurations to close outdated alerts

Code scanning configurations can now be deleted from the code scanning alert page. This could be used to delete stale configurations causing alerts to remain open, or delete old configurations which are no longer used.

Code scanning can be configured to use different tools, target different languages, or even analyze different parts of the codebase in the same repository. In certain circumstances more than one of these configurations may produce the same alert. However, if one of the configurations is no longer used and becomes 'stale' you may find that the alert is fixed in one configuration but not in the stale configuration, which is potentially confusing. Today we are releasing a new feature that allows you to easily delete stale configurations which cause alerts to remain open after they've been fixed.

In the code scanning alert page, the counter in the 'Affected branches' sidebar shows the number of configurations for the branch. Click a branch to view the configuration details, and delete configurations as required. A configuration is deleted for a branch, so may have an impact on the status of other alerts on the same branch. When a configuration is deleted, a timeline entry is recorded on the alert, and repositories in an organization also record an audit log entry. If a configuration is deleted by mistake, re-run the analysis to update the alert and reinstate the configuration.

Delete code scanning configurations

Read more about removing stale code scanning configurations and alerts.

See more

GitHub Actions – Required workflows improvements

Today, we are adding a couple of new improvements to required workflows in GitHub Actions.

  • Blocking direct push: Direct pushes are now blocked on branches of the repositories where required workflows are enforced. To push to a branch where required workflows are enforced at the organizational level, create a pull request to make the necessary changes. If you want to allow direct pushes for a particular repository, you must remove the repository as a target from respective required workflows.

    Block direct push PR

    Block direct push CI

  • Ability to configure required workflows from refs: Required workflows can now be referenced using any branch, tag, or commit SHA from the repository containing the workflow file, during its configuration. This helps you to freeze your required workflow file to a fully validated golden version and gives you the flexibility to move to latest version after testing it thoroughly. The branch, tag, or commit can be specified in the workflow path text field similar to how it is specified for actions within a workflow yaml.

    Required workflows ref

Link to Documentation

Note: Required workflows is currently in beta.

See more
View more changes