GitHub's Advisory Database now supports listing malware advisories. You can see them by searching "type:malware" on https://github.com/advisories.
If you have enabled Dependabot alerts on your repositories, GitHub will send Dependabot alerts for malware automatically. Note that Dependabot does not send update pull requests for malware as the only resolution is to delete the package and find an alternative.
This beta feature allows repository admins to block Git pushes to a repository when they are potentially destructive.
Developers have had branches deleted from their repository when someone pushes changes with Git's --mirror option. The --mirror option is potentially destructive because it makes the remote repository exactly match the local clone. When run by accident, if the remote has more branches or different data than the local clone, many branch deletes and force-pushes can happen at the remote without any warning. This is often embarrassing for the one who pushed and a big challenge to recover from. Here's a real-world example: git push origin –mirror deleted all of my colleagues' branches.
This destructive situation can usually be identified by multiple branch or tag updates being pushed at the same time. The new beta feature being announced here allows admins to block potentially destructive pushes by limiting the number of branches and tags that can be updated by a single push. This can prevent or limit the loss of data.
To use this beta feature, click Settings in a repository that you are an admin of. Next, select General (the default, top-most tab). Then toggle the setting named Limit how many branches and tags can be updated in a single push as shown below. Set the number appropriately for your needs. We recommend the default maximum of 5 branch or tag updates allowed in one push. The minimum value is 2 since two branch updates are required by Git to rename a branch in a single push: delete branch and create branch. Lower numbers are more restrictive of which pushes are allowed, and higher numbers are less restrictive but have more potential for being destructive. As part of this feature's beta, we'd like to learn which number works best for you.
We appreciate feedback on this and other topics in GitHub's public feedback discussions.
The Dependency Review GitHub Action, which checks if pull requests introduce a dependency with a known vulnerability, now supports configuration based on vulnerability severity and license type.
The following configuration options are available:
fail-on-severity: the action will fail on any pull requests that introduce vulnerabilities of the specified severity level or higherallow-licenses: the action will fail on pull requests that introduce dependencies with licenses that do not match the listdeny-licenses: the action will fail on pull requests that introduce dependencies with licenses that match the listThe action is available for all public repositories, as well as private repositories that have Github Advanced Security licensed.
Learn more about dependency review enforcement.
Learn more about configuring the Dependency Review GitHub Action.
Previously, it was difficult to create a new branch from the GitHub UI. Now you can create a branch on the Branches overview page. Just click the New branch button, shown here:
Then, specify the new branch name and source:
Read more about creating a branch. We appreciate feedback on this and other topics in GitHub's public feedback discussions.
Back in March, we introduced a new "For you" feed in Public Beta, to help you discover interesting projects across GitHub. Today, we are sharing a few updates to this beta.
For questions or feedback, visit the GitHub Feed feedback.
Translations are now available for discussion comments in Spanish, Portuguese, Korean, and English. If your first preference browser language is different from the language of the discussion comment, you will now see an option to translate the comment's contents.
This feature is in beta and we'd love your feedback. Leave us a note here and let us know what you think.
Teachers we have heard your feedback! The GitHub Classroom team is excited to announce that now in addition to reusing a single assignment you can reuse multiple assignments across Classrooms and/or from semester-to-semester. You no longer have to manually and repeatedly create new assignments using the same template repo.
Using 'Reuse assignment' on the Classroom level you can copy single / multiple assignments and associated template repo across Classrooms and organizations. The copied assignment will include the Assignment details such as name, source repository, autograding and preferred editor.
These changes will be gradually rolling out over the next week. For more information on how to use this new experience, check out our documentation. Your feedback is welcome at our Education Community Forum.
Today, we're shipping the ability to select multiple Dependabot alerts to reopen or dismiss from the index page UI. For example, from the Closed alerts tab, you can now select multiple alerts that have been previously dismissed, and then reopen them at once.
For more information, see our documentation for Dependabot alerts.
The macOS 12 Actions runner image is now generally available. Start using GitHub Actions to build and publish apps for the Apple ecosystem with the latest version of Xcode by updating your jobs to include runs-on: macos-12
jobs:
build:
runs-on: macos-12
steps:
- uses: actions/checkout@v2
- name: Build
run: swift build
- name: Run tests
run: swift testThe macOS 12 Actions runner image has different tools and tool versions than macOS 11. See the full list of changed software.
If you spot any issues with your workflows when using the image, please let us know by creating an issue in the virtual-environments repository.
Workflows triggered by workflow_dispatch and workflow_call can now access their inputs using the inputs context.
Previously workflow_dispatch inputs were in the event payload. This made it difficult for workflow authors who wanted to have one workflow that was both reusable and manually triggered. Now a workflow author can write a single workflow triggered by workflow_dispatch and workflow_call and use the inputs context to access the input values.
For workflows triggered by workflow_dispatch inputs are still available in the github.event.inputs context to maintain compatibility.
Using the inputs context in GitHub Actions
GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, we help protect users from data leaks and fraud associated with exposed data.
We have partnered with redirect.pizza, a domain redirection service, to scan for their API tokens and help secure our mutual users. Their API keys allow users to create, update, and delete redirects. We'll forward API tokens found in public repositories to redirect.pizza, who will notify the user by email and automatically revoke the token. More information about redirect.pizza’s API tokens can be found here.
GitHub Advanced Security customers can also scan for redirect.pizza API keys and block them from entering their private and public repositories via secret scanning’s push protection feature.
Achievements celebrate specific events and actions that happen on GitHub. They will appear as small badges listed in the sidebar of your profile and are in Public Beta starting today. Check out the blog post to learn more.
To stop private contributions from counting toward your Achievements or to turn off Achievements entirely, see "Showing your private contributions and Achievements on your profile."
You can now use GitHub Mobile to complete your password reset, if you have two-factor authentication enabled.
After you confirm access to your email address, you'll be asked to authenticate with any registered second factor. GitHub Mobile will be the default if you have it installed.
For more information, please see "Updating your GitHub access credentials".
When you visit the GitHub Advisory Database, you can now search for any historical advisory recognized by the National Vulnerability Database.
Previously, we only displayed advisories from our supported ecosystems. We then expanded to have an Unreviewed category for advisories that do not belong to those ecosystems, and we've been auto-publishing new advisories to this category since.
We've now backfilled our database to include all historical advisories from prior years, so you can find any advsiory you may be searching for regardless of publication date. This brings us to over 160 thousand advisories, and counting! You can browse them by clicking the "All unreviewed" button or by searching "type:unreviewed" in the search bar.
GitHub Education now provides a safe place for students to take the first step in their open source journey with the launch of Community Exchange on GitHub Global Campus. Community Exchange offers students the ability to connect with peers to learn valuable skills to contribute to open source.
With Community Exchange, users can discover student created repositories and even submit a repository of their own. By submitting a repository a student can:
Community Exchange is available to all Global Campus students on their Global Campus dashboard. Students who haven't joined Global Campus can apply for GitHub Global Campus benefits.
To learn more about Community Exchange, check out our blog post.
GitHub Advanced Security customers can now use sort and direction parameters in the GitHub REST API when retrieving secret scanning alerts. API users can sort based on the alert’s created or updated fields. The new parameters are available at the enterprise, organization, and repository level API endpoints.
Learn more about the secret scanning REST API
Learn more about private repository scanning with Advanced Security
Organization owners and repository admins can now require developers to sign off on commits made through GitHub's web interface. Also, it is now easier for developers to complete a signoff in the web interface.
Note: Signing off on a commit is different than signing a commit, such as with a GPG key.
The Git command line interface has a --signoff option that developers can use to sign off on their commits. Many open-source organizations require developers to sign off on their changes to affirm compliance with repository rules and licensing. Git's --signoff option appends a specially formatted line to the commit message, as shown here:
Signed-off-by: Mona Lisa <mona@github.com>This text is what constitutes a signoff. It is often called a “DCO signoff” because the most common signoff agreement is the Developer Certificate of Origin (DCO) from the Linux Foundation.
Open-source projects often use pull request checks to block commits from being merged unless they're signed off. Here’s an example of a commit being blocked in the open-source Gradle Profiler repository, which uses the Probot GitHub App to check whether all of a pull request's commits are signed off:
This problem is more likely when committing from GitHub's web interface where Git’s --signoff option isn't available. To sign off there, developers must manually add the Signed-off-by: text to their commit message. That's easy to overlook or misformat, resulting in the commit being blocked from merging. Resolving this situation can be complicated and slow developers down, as shown in these instructions to fix one commit:
In the words of one open-source contributor:
🤦 As a pull request reviewer, this is my biggest pain point. If someone forgets to manually sign off on a commit in the web UI, the pull request check fails and the only resolution is to rebase or squash and force push to fix the commit message. Either way, the review history becomes unclear. This is high friction for new and infrequent contributors and people forget.
Organization owners and repository admins can now require developers to sign off on commits made through GitHub's web interface, such as when editing a file or merging a pull request.
Also, it is now easier for developers to complete a signoff in the web interface, resulting in fewer commits being blocked from merging and less time spent resolving blocked commits.
Organization owners can configure an organization-level setting to require sign off on commits made through the web interface. To do so, click Settings in an organization that you are an owner of. Next, in the navigation under Code, planning, and automation, select Repository and then Repository defaults. Finally, under Commit signoff choose All repositories to require sign off on web-based commits in all repositories in the organization, as shown below. Alternatively, select No policy to disable the setting so that sign off will not be required unless enabled at the repository level.
Repository admins can toggle a similar repository-level setting. To do so, click Settings in a repository that you are an admin of. Next, select General (the default, top-most tab). Then toggle the setting named Require contributors to sign off on web-based commits as shown below. This setting will be overridden by the organization-level setting unless the organization has No policy selected.
When the setting is enabled, the web interface will inform developers that their action of committing will also constitute signing off, as shown below. Like using Git's --signoff option on the command line, signing off in the web interface will automatically append the Signed-off-by: text to the commit message.
Related to this feature, GitHub is planning a Git push policy setting that blocks commits from even entering a repository if they are not signed off. This will apply to commits made in GitHub's web interface or pushed from the Git command line or another Git client.
We appreciate feedback on this and other topics in GitHub's public feedback discussions.
It is now possible to manually select the previous release prior to generating release notes in the GitHub Releases UI.
For more information on Generating Release Notes, see the Automatically Generated Release Notes documentation.
For more information on GitHub Releases, see the GitHub Releases documentation.
Custom repository roles are now GA for GitHub.com and Enterprise Server 3.5.
Organization admins can create custom repository roles available to all repositories in their organization. Roles can be configured from a set of 35 fine grained permissions covering discussions, issues, pull requests, repos, and security alerts. Once a role is created, repository admins can assign a custom role to any individual or team in their repository.
Custom repository roles can be managed in the Repository roles tab of your Organization settings:
Custom repository roles are also supported in the GitHub REST APIs. The Custom Roles API can be used to list all custom repository roles in an organization, and the existing APIs for granting repository access to individuals and teams support custom repository roles.
To get started with custom repository roles, read the docs.
In February 2022, we launched a new feature called community contributions to security advisories.
We have made a handful of changes to the UX based on your feedback: