Second-factor validation after 2FA setup

GitHub.com users who set up two-factor authentication will see a prompt after 28 days, asking them to perform 2FA and confirm their second factor settings. This prompt helps avoid account lockout due to misconfigured authenticator applications (TOTP apps), especially those that failed to save the TOTP secret after validating it during set up.

This prompt appears in existing sessions if you haven't already performed 2FA as part of a sudo prompt or signing in on another device. If you find that you can't perform 2FA, you'll be presented with a shortcut that allows you to reset your 2FA setup.

image

All users that enable 2FA will be eligible for this prompt, including users required to enable it by their organization or GitHub itself.

To learn more about two-factor authentication, see "Configuring two-factor authentication".

GitHub Actions: OpenID Connect token now supports more claims for configuring granular cloud access

OpenID Connect (OIDC) support in GitHub Actions enables secure cloud deployments using short-lived tokens that are automatically rotated for each deployment.
Each OIDC token includes standard claims like the audience, issuer, subject and many more custom claims that uniquely define the workflow job that generated the token. These claims can be used to define fine grained trust policies to control the access to specific cloud roles and resources.

  • We now support more custom claims within the token : actor_id, repository_id, repository_owner_id
    workflow_ref, workflow_sha and job_workflow_sha – to help uniquely verify the source of a workflow job, even if the job references a reusable workflow.
  • We are also adding these new attributes as default environment variables and also to github context

These changes enable developers to define more advanced access policies using OpenID connect and do more secure cloud deployments at scale with GitHub Actions.

Learn more about Security hardening your GitHub Workflows using OpenID Connect.

See more

Packages: Fine-grained permissions and organization-level publishing are now available for the GitHub Packages RubyGems registry

The GitHub Packages RubyGems registry now runs on a new architecture, unlocking great new capabilities:

Publishing packages at organization level with GitHub Packages

Previously, RubyGems packages published to GitHub Packages were closely coupled to their repositories. Now packages can be published at an organization level. They can still be linked to a repository at any time, if needed.

Learn more about connecting a repository to a package.

Fine grained permissions for RubyGems packages published to GitHub Packages

You can now configure Actions and Codespaces repository access on the package's settings page, or invite other users to access the package. Additionally, RubyGems packages published to GitHub Packages can still be configured to automatically inherit all permissions from a linked repository.

Learn more about configuring a package's access control.

Internal visibility

In addition to public and private, a package's visibility can now also be set to internal. It is then visible for all members of the GitHub organization.

These new features are now available to all users on github.com.

Read more about working with the GitHub RubyGems registry

We appreciate your feedback on these new changes in GitHub's public community discussions!

See more
View all changes