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:
The dependency graph now supports detecting Rust (Cargo.{toml,lock}) files. These will be displayed within the dependency graph section in the Insights tab. Users will receive Dependabot alerts and updates for vulnerabilities associated with their Rust dependencies. Package metadata, including mapping packages to repositories, will be added at a later date.
GitHub Enterprise Cloud owners now have the ability to opt-in to display enterprise members’ IP addresses for all
events involving enterprise-owned private repositories and enterprise-owned assets, such as issues and projects, in your
audit log.
This additional information can be used to improve threat analyses and
further secure your software.
Note, IP addresses will continue to not be displayed for activity related to public repositories.
For additional information, read about displaying IP addresses in the audit log for your enterprise.
Dependabot version updates help you keep your dependencies up-to-date by opening pull requests automatically when new versions are available.
With this release, you can now more easily enable and configure Dependabot version updates from your repository’s settings page. Within the "Dependabot" section of the "Code security and analysis" tab, you can choose to enable Dependabot version updates, which will prompt you to create a dependabot.yml config file. If a dependabot.yml file exists, you can access that from the repository settings page.
Note: you still need to configure Dependabot version updates with a dependabot.yml file to enable it.
For more information, learn more about Dependabot version updates and how to configure a dependabot.yml file.
Today's Changelog brings you the release of project webhooks, a first exploration into templates and a host of improvements to GitHub Issues.
The first release of webhooks for projects (beta) is now available for Organizations and GitHub Apps. 🤩
Once configured and enabled, webhooks will transmit events for any action taken on project items within your organization. This includes changes made (via projects) to status, assignee, labels, and even draft issue titles and descriptions!
You can find webhooks for projects (beta) in the "Webhooks" section of your organization settings page under the title Projects v2 Items. For more information, including technical specifications, check out the docs.
🦻 We're still developing webhooks, and we'd love to hear your feedback; drop us a line in our Feedback Discussion.
When you create a new project, you now have the option of multiple templates to choose from. Start with either the default table or board, or explore one we've created for you with our team backlog or feature templates.
Stay tuned for more with templates in the future. 💖
Quickly understand which organization or user a project belongs to and easily navigate via the breadcrumbs in the project header. We've got more to do here, so please let us know what you think.
Other changes include:
assignee filter menu on the issues index page, you now have the option to filter by the current user instantly, without having to wait for all possible assignees to load.See how to use GitHub for project planning with GitHub Issues, check out what's on the roadmap, and learn more in the docs.
Code scanning flags up potential security vulnerabilities in pull requests — well before code is merged and deployed. Starting today, such alerts will be more visible: they will appear as a review on the pull request Conversation tab. As with any review, developers can then have a conversation about specific areas of the code that was changed.
And of course, from the code review by the GitHub code scanning bot, you can dive deeper into the alert: view the details, check the data flow paths, and dismiss an alert.
Users were already able to configure code scanning as a required check in the branch protection settings in a repository.
With the new code scanning functionality, developers can start a conversation about code scanning alerts. Branch protection rules that require all conversations to be resolved before a PR can be merged apply equally to conversations about code scanning alerts: as soon as a code reviewer comments on a code scanning alert, the PR can not be merged until the conversation is marked as resolved. This helps ensure comments made on alerts are addressed prior to merging.
As you'd expect, when an alert is fixed, the conversation around the alert gets resolved and the PR can be merged.
Learn more about GitHub Advanced Security and code scanning.
You can now sign up to be sponsored via GitHub Sponsors if you have a bank account and tax residence in Brazil. Read about the rollout on our blog and stay tuned for more news on expansion.
As always, you can sponsor projects from wherever GitHub does business and join the Sponsors waitlist if we’re not yet in your region.
Users can now add a comment when dismissing a code scanning alert.
It is optional to provide a dismissal comment. Dismissal comments are recorded in the alert timeline. They can also be set via the code scanning REST API when updating an alert, and retrieved through the new dismissed_comment attribute.
This feature is now available to all users on GitHub.com and will be released in GHES 3.6.
Enterprises that use Enterprise Managed Users (EMUs) to authenticate their accounts via Azure Active Directory can now use Azure AD location-based Conditional Access policies to protect the use of PATs and SSH keys. This requires the use of a new OpenID Connect-based application rather than a SAML integration. To learn more, read about enforcing Azure AD Conditional Access for PATs and SSH keys.
Note: this feature is currently in public beta for new and existing Azure AD EMU enterprises.
For more information:
You can now download the latest version of GitHub Enterprise Server. This new release introduces GitHub Container registry and continues the strong emphasis on security. Your teams will be able to take advantage of the full complement of Dependabot capabilities and use GitHub Advanced Security with even greater language coverage and better protection for your secrets. You can read a detailed summary of new features for this release in the GitHub blog or you can take a look at all the changes in the release notes. You can check out a few of these highlights:
New and of particular interest to administrators:
To learn more about all the new features in GitHub Enterprise Server 3.5, read the release notes or download it today. Are you using the latest GitHub Enterprise Server version? Use the Upgrade Assistant to find the upgrade path from your current version of GitHub Enterprise Server to your desired version.
Two-Factored Authentication (2FA) is now enforced for maintainers of the top-500 packages, by dependents, on the npm registry.
To learn more about configuring 2FA, see Configuring two-factor authentication.
To learn more about 2FA in general, see About two-factor authentication.
For questions and comments, open a discussion in our feedback repository.
GitHub will now verify Git commit signatures and show commits as "Verified" even if their public GPG signing keys are expired or revoked (but not compromised). You can also upload GPG keys that are expired or revoked to your GitHub user profile.
Using GPG or S/MIME, you can sign Git commits. These commits are marked "Verified" in GitHub's web interface, giving others confidence that they come from a trusted source because they carry their committer's signature.
GPG keys often expire or are revoked when no longer used. Previously, when a public GPG key stored in a GitHub user profile was expired or revoked, all commits that had ever been signed with that key would be shown as "Unverified" on GitHub. That raised unnecessary concern since the commits were validly signed before their key was expired or revoked. Now, when a user's GPG key expires or is revoked for a reason other than being compromised, GitHub will continue showing commits that were previously signed with that key as "Verified." You can also upload GPG keys that are expired or revoked. Besides maintaining trust in commits’ sources, this allows GPG keys to be added or rotated for greater security without losing the “Verified” status of previously signed commits.
For more information, visit About commit signature verification in the GitHub documentation.
We appreciate feedback on this and other topics in GitHub's public feedback discussions.