Skip to content

Secret scanning summary email for historical scans

If you are an organization or enterprise owner, you will now receive a secret scanning summary email when the historical scan completes. The email notification will tell you how many, if any, secrets were detected across all repositories within your organization or enterprise. You'll also receive a link to your security overview page for each secret, where you can view details for each detected secret.

Previously, secret scanning would send one email per repository where secrets were detected, provided that you were watching the repository and had email notifications enabled in your user settings enabled. While repository administrators will still receive an email notification per repository, organization and enterprise owners will now receive only a single notification upon the historical scan's completion.

To receive notifications:

  • For the first historical scan after you enable secret scanning, you must have email notifications enabled in your user settings. You do not need to watch any repositories to receive the secret scanning summary email.
  • For future historical scans, such as for newly added patterns, you will receive an email notification for each repository where a secret was found. You must be watching the repository where the secret was detected and have email notifications enabled in your user settings.

summary email after backfill scan

Codespaces Settings Sync Updates

Codespaces now supports two-way Settings Sync with VS Code for the Web

Visual Studio Code enables users to Sync Settings between VS Code environments. Codespaces exposes this capability as a way to personalize your experience. Prior to this release, Settings Sync for the VS Code web client was one-way by default, and two-way sync had to be enabled manually for each codespace.

With today's release, you can now choose whether to enable Settings Sync. Settings Sync is off by default. If you enable Settings Sync, the sync is two-way for repositories you trust, and one-way for untrusted repositories. Codespaces will also remember your choice.

The quickest way to enable Settings Sync is to start a codespace using the VS Code for the Web client, then choose 'Turn on Settings Sync…'

Turn on Settings Sync in VS Code web client

You will then be prompted for permission to enable Settings Sync for the repository. If you authorize, the Settings Sync setting on your GitHub profile will be enabled, and the repository will be added to a list of trusted repositories so that future codespaces on that repository will automatically have Settings Sync enabled in VS Code for the Web.
cVS Code Settings Sync is requesting additional permissions

You can manage your Settings Sync and GPG verification settings from your GitHub Codespaces Settings page at
https://github.com/settings/codespaces.

On the Codespaces settings page you can manage which repositories you trust for GPG verification and Settings Sync.
Codespaces Settings for GPG verification and Settings Sync

Trusted repositories

Settings Sync and GPG verification now share a single set of trusted repositories. You can enable or disable GPG verification and Settings Sync independently. If you have Settings Sync enabled and you open a codespace from a repository that is not in your list of trusted repositories, the Settings Sync will be read only – your settings will be pulled from the Settings Sync server and applied to your codespace, but no settings changes will be written back. If you open a codespace for a repository you do trust, your settings will be synced both to and from the server.

If you have enabled GPG verification for all repositories, we advise you to restrict the repositories to a trusted list when you first enable Settings Sync.

VS Code Settings Sync is requesting additional permissions when all repositories are trusted

If you choose to enable Settings Sync for all repositories we will keep that setting for GPG verification as well, but we recommend restricting both Settings Sync and GPG verification to trusted repositories to improve your security posture.

See more

GitHub Actions: All Actions will run on Node16 instead of Node12

Node 12 has been out of support since April 2022, as a result we have started the deprecation process of Node 12 for GitHub Actions. We plan to migrate all actions to run on Node16 by Summer 2023.
Following on from our warning in workflows using Node 12, we will start enforcing the use of Node16 rather than Node12 on the 14th of June.

What you need to do
For Actions maintainers: Update your actions to run on Node 16 instead of Node 12 (Actions configuration settings)
For Actions users: Update your workflows with latest versions of the actions which runs on Node 16 (Using versions for Actions)

See more
View all changes