Enterprise Server 3.2 release notes

Enterprise Server 3.2.1


October, 12, 2021

Security fixes
  • Packages have been updated to the latest security versions.

Bug fixes
  • Custom pre-receive hooks could have failed due to too restrictive virtual memory or CPU time limits.

  • In a GitHub Enterprise Server clustering configuration, Dependency Graph settings could have been incorrectly applied.

  • Attempting to wipe all existing configuration settings with ghe-cleanup-settings failed to restart the Management Console service.

  • During replication teardown via ghe-repl-teardown Memcached failed to be restarted.

  • During periods of high load, users would receive HTTP 503 status codes when upstream services failed internal healthchecks.

  • Pre-receive hook environments were forbidden from calling the cat command via BusyBox on Alpine.

  • Failing over from a primary Cluster datacenter to a secondary Cluster datacenter succeeds, but then failing back over to the original primary Cluster datacenter failed to promote Elasticsearch indicies.

  • The "Import teams" button on the Teams page for an Organization returned an HTTP 404.

  • Using the API to disable Secret Scanning correctly disabled the property but incorrectly returned an HTTP 422 and an error message.

  • In some cases, GitHub Enterprise Administrators attempting to view the Dormant users page received 502 Bad Gateway or 504 Gateway Timeout response.

  • Performance was negatively impacted in certain high load situations as a result of the increased number of SynchronizePullRequestJob jobs.

  • A user defined pattern created for Secret Scanning would continue getting scanned even after it was deleted.

  • GitHub Apps now set the Secret Scanning feature on a repository consistently with the API.

Known issues
  • On a freshly set up GitHub Enterprise Server without any users, an attacker could create the first admin user.

  • Custom firewall rules are removed during the upgrade process.

  • Git LFS tracked files uploaded through the web interface are incorrectly added directly to the repository.

  • Issues cannot be closed if they contain a permalink to a blob in the same repository, where the blob's file path is longer than 255 characters.

  • When "Users can search GitHub.com" is enabled with GitHub Connect, issues in private and internal repositories are not included in GitHub.com search results.

  • The GitHub Packages npm registry no longer returns a time value in metadata responses. This was done to allow for substantial performance improvements. We continue to have all the data necessary to return a time value as part of the metadata response and will resume returning this value in the future once we have solved the existing performance issues.

  • Resource limits that are specific to processing pre-receive hooks may cause some pre-receive hooks to fail.

Enterprise Server 3.2.0


September, 28, 2021

📣 これはEnterprise Serverの最新のパッチリリースではありません。 最新のセキュリティ、パフォーマンス、バグフィックスのために、最新のリリースをお使いください。

For upgrade instructions, see "Upgrading GitHub Enterprise Server."


    Secret Scanningのカスタムパターン

  • GitHub Advanced Securityのお客様は、Secret scanningでカスタムパターンを指定できるようになりました。新しいパターンが指定されると、Secret scanningは新しいコミットとともに、リポジトリのGit履歴全体に対してそのパターンを検索します。

    ユーザ定義パターンは、GitHub Enterprise Server 3.2ではベータです。ユーザ定義パターンは、リポジトリ、Organization、Enterpriseのレベルで定義できます。詳しい情報については「Secret scanningのカスタムパターンの定義」を参照してください。

  • Advanced Security(ベータ)のセキュリティの概要

  • GitHub Advanced Securityのお客様は、code scanning、Dependabot、secret scanningによって検出されたアプリケーションのセキュリティリスクのOrganizationレベルのビューを利用できるようになりました。このセキュリティの概要は、検出されたアラート数とともに、それぞれのリポジトリにおけるセキュリティ機能の有効化の状況を示します。

    加えて、このセキュリティの概要はすべてのsecret scanningアラートをOrganizationレベルでリストします。Dependabot及びcode scanningアラートの同様のビューが、将来のリリースで導入されます。詳しい情報に付いては「セキュリティの概要について」を参照してください。


  • 依存関係レビュー(ベータ)

  • GitHub Advanced Securityのお客様は、Pull Request内で変更された依存関係のリッチdiffを見ることができるようになりました。依存関係レビューは、Pull Requestの"Files changed"タブで、依存関係の変更とそのセキュリティへのインパクトの理解しやすいビューを提供します。これは、追加、削除、更新された依存関係を、それらについての脆弱性の情報とともに知らせてくれます。詳しい情報については「Pull Request内での依存関係の変更のレビュー」を参照してください。

  • GitHub Actionsの環境

  • 環境、環境保護ルール、環境シークレットはGitHub Enterprise Server上のGitHub Actionsで一般に利用可能になりました。詳しい情報については「環境」を参照してください。


  • セキュリティキーによるSSH認証

  • sk-ecdsa-sha2-nistp256@openssh.comあるいはsk-ssh-ed25519@openssh.comSSHキーをアカウントに追加すると、FIDO2セキュリティキーを使ったSSH認証がサポートされるようになりました。SSHセキュリティキーは、セキュリティキーの実体を、利用に際してタップのような検証を必要とする個別のハードウェアデバイスに保存します。詳しい情報については「 新しいSSHキーの生成とssh-agentへの追加」を参照してください。

  • ダーク及びダーク淡色テーマ

  • Web UIでダーク及びダーク淡色テーマが利用できるようになりました。GitHub Enterprise Serverは、GitHub Enterprise Serverでテーマの環境設定を設定していない場合、システムの環境設定に合わせます。また、昼間と夜間でアクティブにするテーマを選択できます。詳しい情報については「テーマ設定の管理」を参照してください。


  • メール通知のための未検証ドメインの承認

  • 検証不能なドメインを、メール通知のルーティングで承認できるようになりました。Enterprise及びOrganizationのオーナーは、ドメインを承認し、すぐにメール通知の制限ポリシーを拡張し、通知をコラボレータ、コンサルタント、買収先、その他のパートナーに送信できるようにすることができます。詳しい情報については「Enterpriseでのドメインの検証もしくは承認」及び「Enterpriseでのメール通知の制限」を参照してください。

  • セキュアな認証情報ストレージGit Credential Manager (GCM)と多要素認証のサポート

  • Git Credential Manager (GCM) Coreバージョン2.0.452以降は、セキュリティ強化された認証情報のストレージと、GitHub Enterprise Serverのための多要素認証を提供します。

    GitHub Enterprise ServerをサポートするGCM CoreはGit for Windowsバージョン2.32以降に含まれています。GCM Coreは、Git for macOSもしくはLinuxには含まれていませんが、個別にインストールすることはできます。詳しい情報については、 microsoft/Git-Credential-Manager-Coreリポジトリ中の最新のリリース及びインストール手順を参照してください。



  • Enterprise設定に、'User Agent Referrer Policy''設定が追加されました。これによって、外部のサイトからGitHub Enterprise Serverのインストールのホスト名を隠蔽する、厳格なReferrer-Policyを管理者が設定できるようになります。この設定はデフォルトで無効になっており、スタッフやEnterpriseのオーナーが有効化あるいは無効化した場合は監査ログイベントで追跡されます。詳しい情報については「Enterpriseのリファラーポリシーの設定」を参照してください。

  • MySQLのヘルスチェックはTCPのチェックの代わりにmysqladmin pingを使うよう変更され、これによってMySQLのエラーログから不要なノイズが取り除かれます。また、オーケストレーターのフェイルオーバーチェックが改善され、クラスタ設定の変更適用時の不要なMySQLのフェイルオーバーが回避されるようになりました。

  • バックグラウンドジョブの処理をサポートするレスキューサービスが、Aqueduct Liteで置き換えられました。この変更によってジョブシステムは管理しやすくなり、ユーザ体験には影響はないはずです。Aqueductの新しい管理及びデバッギングコマンドについては、「コマンドラインユーティリティ」を参照してください。

  • トークンの変更

  • GitHub Enterprise Serverのための認証トークンのフォーマットは変更されました。この変更は、個人アクセストークンのフォーマットと、OAuth Appのためのアクセストークンとともに、GitHub Appsのためのuser-to-server、server-to-server、リフレッシュトークンに影響します。

    様々なトークンの種類は、一意の特定可能なプレフィックスを持つようになったので、Secret scanningにそれらのトークンを検出してもらい、誰かがうっかりトークンをリポジトリにコミットしてしまった場合のインパクトを緩和できます。GitHubは、既存のトークンをできるだけ早く更新することをおすすめします。詳しい情報については「GitHubでの認証について」及び「secret scanningについてを参照してください。

  • リポジトリの変更

  • ユーザプロフィールとOrganizationプロフィール上のリポジトリは、Star数でのソートをサポートするようになりました。

  • 1つのファイルのコミット履歴を表示させている場合、をクリックして履歴中の選択した時点でのそのファイルを表示できるようになりました。

  • サブモジュールがGitHub Enterprise Serverのインスタンス中で相対パスで定義されている場合、そのサブモジュールがWeb UI中でクリックできるようになりました。Web UIでサブモジュールをクリックすると、リンクしたリポジトリに行くことができます。以前は、絶対URLのサブモジュールだけがクリック可能でした。これは、同じオーナーの../REPOSITORYというパターンに従うリポジトリの相対パスか、異なるオーナーの../OWNER/REPOSITORYというパターンに従うリポジトリの相対パスでサポートされています。サブモジュールの扱いに関する詳しい情報については、GitHub ブログのサブモジュールの扱いを参照してください。

  • Web UIを使用して、古くなったフォークを上流のブランチと同期できるようになりました。ブランチ間でマージコンフリクトがない場合、ブランチはfast-forwardingもしくは上流からのマージによって更新されます。コンフリクトがある場合、そのコンフリクトを解決するためのPull Requestの作成が求められます。詳しい情報については「フォークの同期」を参照してください。

  • Markdownの変更

  • The markdown editor used when creating or editing a release in a repository now has a text-editing toolbar. For more information, see "Managing releases in a repository."

  • Uploading video files is now supported everywhere you write Markdown on GitHub Enterprise Server. Share demos, reproduction steps, and more in your issue and pull request comments, as well as in Markdown files within repositories, such as READMEs. For more information, see "Attaching files."

  • Markdown files will now automatically generate a table of contents in the header when there are 2 or more headings. The table of contents is interactive and links to the selected section. All 6 Markdown heading levels are supported.

  • There is a new keyboard shortcut, cmd+e on macOS or ctrl+e on Windows, to insert codeblocks in Markdown files, issues, pull requests, and comments.

  • Appending ?plain=1 to the URL for any Markdown file will now display the file without rendering and with line numbers. The plain view can be used to link other users to specific lines. For example, appending ?plain=1#L52 will highlight line 52 of a plain text Markdown file. For more information, "Creating a permanent link to a code snippet."

  • Issues and pull requests changes

  • With the latest version of Octicons, the states of issues and pull requests are now more visually distinct so you can scan their status more easily. For more information, see GitHub ブログ.

  • A new "Require conversation resolution before merging" branch protection rule and "Conversations" menu is now available. Easily discover your pull request comments from the "Files changed" tab, and require that all your pull request conversations are resolved before merging. For more information, see "About pull request reviews" and "About protected branches."

  • To prevent the merge of unexpected changes after auto-merge is enabled for a pull request, auto-merge is now disabled automatically when new changes are pushed by a user without write access to the repository. Users without write access can still update the pull request with changes from the base branch when auto-merge is enabled. To prevent a malicious user from using a merge conflict to introduce unexpected changes to the pull request, auto-merge for the pull request is disabled if the update causes a merge conflict. For more information about auto-merge, see "Automatically merging a pull request."

  • People with maintain permissions can now manage the repository-level "Allow auto-merge" setting. This setting, which is off by default, controls whether auto-merge is available on pull requests in the repository. Previously, only people with admin permissions could manage this setting. Additionally, this setting can now by controlled using the "Create a repository" and "Update a repository" REST APIs. For more information, see "Managing auto-merge for pull requests in your repository."

  • The assignees selection for issues and pull requests now supports type ahead searching so you can find users in your organization faster. Additionally, search result rankings have been updated to prefer matches at the start of a person's username or profile name.

  • When a review is requested from a team of more than 100 people, developers are now shown a confirmation dialog box in order to prevent unnecessary notifications for large teams.

  • Back-tick code blocks are now supported in issue titles, pull request titles, and in any place issue and pull request titles are referenced in GitHub Enterprise Server.

  • Events for pull requests and pull request reviews are now included in the audit log for both enterprises and organizations. These events help admins better monitor pull request activity and help ensure security and compliance requirements are being met. Events can be viewed from the web UI, exported as CSV or JSON, or accessed via REST API. You can also search the audit log for specific pull request events. For more information, see "Reviewing the audit log for your organization."

  • Branches changes

  • The default branch name for new repositories is now main. Existing repositories are not impacted by this change. If users, organization owners, or enterprise owners have previously specified a default branch for new repositories, they are also not impacted.

    If you want to set a different default branch name, you can do so in the user, organization, or enterprise settings.

  • Branches, including the default branch, can now be renamed using the the GitHub Enterprise Server web UI. When a branch is renamed, any open pull requests and draft releases targeting the renamed branch will be retargeted automatically, and branch protection rules that explicitly reference the renamed branch will be updated.

    Admin permissions are required to rename the default branch, but write permissions are sufficient to rename other branches.

    To help make the change as seamless as possible for users:

    • A notice is shown to contributors, maintainers, and admins on the repository homepage with instructions for updating their local repository.
    • Web requests to the old branch will be redirected.
    • A "moved permanently" HTTP response will be returned to REST API calls.
    • An informational message is displayed to Git command line users that push to the old branch.

    For more information, see "Renaming a branch."

  • GitHub Actions changes

  • GitHub Actions now lets you control the permissions granted to the GITHUB_TOKEN secret. The GITHUB_TOKEN is an automatically-generated secret that lets you make authenticated calls to the API for GitHub Enterprise Server in your workflow runs. GitHub Actions generates a new token for each job and expires the token when a job completes. The token usually has write permissions to a number of API endpoints, except in the case of pull requests from forks, which are always read. These new settings allow you to follow a principle of least privilege in your workflows. For more information, see "Authentication in a workflow."

  • GitHub CLI 1.9 and later allows you to work with GitHub Actions in your terminal. For more information, see the GitHub changelog.

  • The audit log now includes events associated with GitHub Actions workflow runs. This data provides administrators with a greatly expanded data set for security and compliance audits. For more information, see "Reviewing the audit log for your organization."

  • GitHub Enterprise Server 3.2 contains performance improvements for job concurrency with GitHub Actions. For more information on the new performance targets on a range of CPU and memory configurations, see "Getting started with GitHub Actions for GitHub Enterprise Server."

  • The GitHub Actions Runner application in GitHub Enterprise Server 3.2 has been updated to v2.279.0.

  • GitHub Packages changes

  • Any package or package version for GitHub Packages can now be deleted from GitHub Enterprise Server's web UI. You can also undo the deletion of any package or package version within 30 days. For more information, see "Deleting and restoring a package".

  • Dependabot and Dependency graph changes

  • The dependency graph can now be enabled using the Management Console, rather than needing to run a command in the administrative shell. For more information, see "Enabling alerts for vulnerable dependencies GitHub Enterprise Server."

  • Notifications for multiple Dependabotアラート are now grouped together if they're discovered at the same time. This significantly reduces the volume of Dependabot alert notifications that users receive. For more information, see the GitHub changelog.

  • Dependency graph and Dependabotアラート now support Go modules. GitHub Enterprise Server analyzes a repository's go.mod files to understand the repository’s dependencies. Along with security advisories, the dependency graph provides the information needed to alert developers to vulnerable dependencies. For more information about enabling the dependency graph on private repositories, see "Securing your repository."

  • The default notification settings for security alerts have changed. Previously, if you had permission to view security alerts in a repository, you would receive notifications for that repository as long as your settings allowed for security alert notifications. Now, you must opt in to security alert notifications by watching the repository. You will be notified if you select All Activity or configure Custom to include Security alerts. All existing repositories will be automatically migrated to these new settings and you will continue to receive notifications; however, any new repositories will require opting-in by watching the repository. For more information see "Configuring notifications for vulnerable dependencies" and "Managing alerts from secret scanning."

  • Code scanning and secret scanning changes

  • Code scanning with CodeQL now generates diagnostic information for all supported languages. This helps check the state of the created database to understand the status and quality of performed analysis. The diagnostic information is available starting in version 2.5.6 of the CodeQL CLI. You can see the detailed diagnostic information in the GitHub Actions logs for CodeQL. For more information, see "Viewing code scanning logs."

  • Code scanning with CodeQL CLI now supports analyzing several languages during a single build. This makes it easier to run code analysis to use CI/CD systems other than GitHub Actions. The new mode of the codeql database create command is available starting version 2.5.6 of the CodeQL CLI. For more information about setting this up, see "Installing CodeQL CLI in your CI system."

  • Code scanning alerts from all enabled tools are now shown in one consolidated list, so that you can easily prioritize across all alerts. You can view alerts from a specific tool by using the "Tool" filter, and the "Rule" and "Tag" filters will dynamically update based on your "Tool" selection.

  • Code scanning with CodeQL now includes beta support for analyzing C++20 code. This is only available when building codebases with GCC on Linux. C++20 modules are not supported yet.

  • The depth of CodeQL's analysis has been improved by adding support for more libraries and frameworks and increasing the coverage of our existing library and framework models for several languages (C++, JavaScript, Python, and Java). As a result, CodeQL can now detect even more potential sources of untrusted user data, review the steps through which that data flows, and identify potentially dangerous sinks in which this data could end up. This results in an overall improvement of the quality of the code scanning alerts. For more information, see the GitHub changelog.

  • Code scanning now shows security-severity levels for CodeQL security alerts. You can configure which security-severity levels will cause a check failure for a pull request. The severity level of security alerts can be critical, high, medium, or low. By default, any code scanning alerts with a security-severity of critical or high will cause a pull request check failure.

    Additionally, you can now also configure which severity levels will cause a pull request check to fail for non-security alerts. You can configure this behavior at the repository level, and define whether alerts with the severity error, warning, or note will cause a pull request check to fail. By default, non-security code scanning alerts with a severity of error will cause a pull request check failure.

    For more information see "Defining which alert severity levels cause pull request check failure."

    List of code scanning alerts with security levels

  • Improvements to the branch filter for code scanning alerts make it clearer which code scanning alerts are being displayed on the alerts page. By default, code scanning alerts are filtered to show alerts for the default branch of the repository only. You can use the branch filter to display the alerts on any of the non-default branches. Any branch filter that has been applied is shown in the search bar.

    The search syntax has also been simplified to branch:<branch name>. This syntax can be used multiple times in the search bar to filter on multiple branches. The previous syntax, ref:refs/heads/<branch name>, is still supported, so any saved URLs will continue to work.

  • Free text search is now available for code scanning alerts. You can search code scanning results to quickly find specific alerts without having to know exact search terms. The search is applied across the alert's name, description, and help text. The syntax is:

    • A single word returns all matches.
    • Multiple search words returns matches to either word.
    • Words in double quotes returns exact matches.
    • The keyword 'AND' returns matches to multiple words.
  • Secret scanning added patterns for 23 new service providers. For the updated list of supported secrets, see "About secret scanning."

  • API の変更

  • Pagination support has been added to the Repositories REST API's "compare two commits" endpoint, which returns a list of commits reachable from one commit or branch, but unreachable from another. The API can also now return the results for comparisons over 250 commits. For more information, see the "Repositories" REST API documentation and "Traversing with pagination."

  • The REST API can now be used to programmatically resend or check the status of webhooks. For more information, see "Repositories," "Organizations," and "Apps" in the REST API documentation.

  • Improvements have been made to the code scanning and GitHub Advanced Security APIs:

    • The code scanning API now returns the CodeQL query version used for an analysis. This can be used to reproduce results or confirm that an analysis used the latest query. For more information, see "Code scanning" in the REST API documentation.
    • Admin users can now use the REST API to enable or disable GitHub Advanced Security for repositories, using the security_and_analysis object on repos/{org}/{repo}. In addition, admin users can check whether Advanced Security is currently enabled for a repository by using a GET /repos/{owner}/{repo} request. These changes help you manage Advanced Security repository access at scale. For more information, see "Repositories" in the REST API documentation.
Known issues
  • 新しくセットアップされたユーザを持たないGitHub Enterprise Serverで、攻撃者が最初の管理ユーザを作成できました。

  • アップグレードの過程で、カスタムのファイアウォールのルールが削除されます。

  • Git LFSが追跡するファイルWebインターフェースからアップロードされたものが、不正にリポジトリに直接追加されてしまいます。

  • 同じリポジトリ内のファイルパスが255文字を超えるblobへのパーマリンクを含むIssueをクローズできませんでした。

  • GitHub Connectで"Users can search GitHub.com"が有効化されている場合、GitHub.comの検索結果にプライベート及びインターナルリポジトリのIssueが含まれません。

  • GitHub Packagesのnpmレジストリは、メタデータのレスポンス中で時間の値を返さなくなります。これは、大きなパフォーマンス改善のために行われました。メタデータレスポンスの一部として時間の値を返すために必要なすべてのデータは保持し続け、既存のパフォーマンスの問題を解決した将来に、この値を返すことを再開します。

  • pre-receive フックの処理に固有のリソース制限によって、pre-receive フックに失敗するものが生じることがあります。





GitHubのすべてのドキュメントはオープンソースです。間違っていたり、はっきりしないところがありましたか?Pull Requestをお送りください。


OR, コントリビューションの方法を学んでください。