Top-500 npm package maintainers now require 2FA

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.

Improved verification of historic Git commit signatures

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.

An image of GitHub showing a commit's signature as verified even though its public GPG key is expired

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.

See more

Easily discover and navigate to multiple licenses in repositories

We’ve made it easier to discover multiple licenses within an open source repository. First, navigate to the **About** sidebar on the repository page to see if the repository contains any licenses. If it does, they’ll be listed underneath the README file.

sidebar-view-of-licenses

If only one license is detected, the link will take you directly to that license file. If more than one license is present, click on the list of licenses to display a dialog containing all of the licenses available at the root level of the repository. Then you can select from the dialog which license you’d like to navigate to.

dialog-of-multiple-licenses

With the use of an open source Ruby gem called Licensee, we detect license files and compare them to a short list of known licenses. Learn more about how repositories on GitHub are licensed.

Adding an open source license to your repository ensures that others can use, copy, modify and contribute back to your project. If your repository doesn’t have an open source license and you want others to get involved, you can learn more about adding one here. The dialog will match any top-level licenses with a variation of LICENSE, COPYING, OFL and PATENTS, including file extensions (i.e. LICENSE-MIT, LICENSE-GPL).

See more
View all changes