Enterprise Server 3.2 release notes

HIGH: Updated dependencies for the Management Console to the latest patch versions, which addresses security vulnerabilities including CVE-2022-30123 and CVE-2022-29181.

HIGH: Added checks to address an improper cache key vulnerability that allowed an unauthorized actor to access private repository files through a public repository. This vulnerability has been assigned CVE-2022-23738.

MEDIUM: Updated CommonMarker to address a scenario where parallel requests to the Markdown REST API could result in unbounded resource exhaustion. This vulnerability has been assigned CVE-2022-39209.

LOW: Due to a CSRF vulnerability, a GET request to the instance's site/toggle_site_admin_and_employee_status endpoint could toggle a user's site administrator status unknowingly.

After a site administrator installed a hotpatch containing changes to web interface assets such as JavaScript files or images, the instance did not serve the new assets.

HIGH: A GitHub App could use a scoped user-to-server token to bypass user authorization logic and escalate privileges.

MEDIUM: The use of a Unicode right-to-left override character in the list of accessible files for a GitHub App could obscure additional files that the app could access.

Packages have been updated to the latest security versions.

In a cluster configuration, running ghe-cluster-config-apply could cause unconfigured nodes to replicate configuration to the rest of the cluster, potentially removing configurations from existing nodes.

In some cases, the Management Console's monitor dashboard would not load correctly.

When sending a support bundle to GitHub Enterprise Support using ghe-support-upload, the -t option would not successfully associate the uploaded bundle with the specified ticket.

After a user deleted or restored packages from the web interface, counts for packages could render incorrectly.

Manually disabled GitHub Actions workflows in a repository were re-enabled if the repository received a push containing more than 2048 commits, or if the repository's default branch changed.

When using a VPC endpoint URL as an AWS S3 URL for GitHub Packages, publication and installation of packages failed.

管理コンソールと /home/admin/.ssh/authorized_keys ファイルの両方に、重複する管理 SSH キーが表示されることがありました。

� �合によっては、スレッドセーフではないにも関わらず同時に使われたライブラリのため、バックグラウンド タスクが停止することがありました。

並列化されたログ サニタイズの結果、サポート バンドルの生成が速くなっています。サポート バンドルについて詳しくは、「GitHub Support へのデータの提供」をご覧く� さい。

CRITICAL: GitHub Enterprise Server's Elasticsearch container used a version of OpenJDK 8 that was vulnerable to an integer truncation issue when processing malicious XSLT stylesheets. The vulnerability is tracked as CVE-2022-34169.

HIGH: Previously installed apps on user accounts were automatically granted permission to access an organization on scoped access tokens after the user account was transformed into an organization account. This vulnerability was reported via the GitHub Bug Bounty program.

When a custom dormancy threshold was set for the instance, suspending all dormant users did not reliably respect the threshold. For more information about dormancy, see "Managing dormant users."

中: サーバー側リクエスト フォージェリ (SSRF) によって Subversion (SVN) ブリッジを強制し、任意のデータを Memcached に挿入することによりリモート コードを実行する可能性のある攻撃を防ぎます。

Grafana をバージョン 7.5.16 に更新します。これにより、CVE-2020-13379 や CVE-2022-21702 などのさまざまなセキュリティの脆弱性が対処されます。

パッケージは最新のセキュリティ バージョンに更新されました。

MEDIUM: A vulnerability involving deserialization of untrusted data was identified in GitHub Enterprise Server that could potentially lead to remote code execution on the Subversion (SVN) bridge. To exploit this vulnerability, an attacker would need to gain access via a server-side request forgery (SSRF) that would let an attacker control the data being deserialized. This vulnerability was reported via the GitHub Bug Bounty program and has been assigned CVE-2022-23734.

解凍ツールを使って解凍すると成果物の zip アーカイブ内のファイルのアクセス許可が 000 になった問題を修正しました。現在は、GitHub.com での動作と同じように、ファイルのアクセス許可は 644 に設定されます。

collectd デーモンのメモリ消費が多すぎることがありました。

� �合によっては、ローテーションされたログ ファイルのバックアップが蓄積し、ストレージを消費し過ぎることがありました。

新しい機能リリースにアップグレードしてから構成を実行した後、インデックスの再構築の間に Elasticsearch が過剰な例外をログすることがありました。

複数の承認レビューを必要とする保護されたブランチで、pull request がマージされる承認レビューが必要な数より少ない� �合がありました。

LDAP 認証を使うインスタンスで、ユーザー名とパスワード両方のテキスト フィールドが表示されていると、sudo モードの認証プロンプトにより、既定でカーソルがパスワード フィールド内に誤って配置されました。

インスタンスが回復モードで起動されるとき、ghe-set-password コマンド ラインユーティリティは必要なサービスを自動的に開始します。

aqueduct バックグラウンド プロセスのメトリックが Collectd 転送について収集され、管理コンソールに表示されます。

データベース移行と構成実行のログの� �所 /data/user/common/ghe-config.log が、進行中の移行の詳細のページに表示されるようになります。

中: サーバー側セキュリティ フォージェリ (SSRF) 攻撃の可能性を防ぐため、github.company.com と github-company.com が内部サービスによって同じホスト名として評価されないようにします。

低: 外部ファイアウォール規則によって HTTP アクセスがブロックされている� �合であっても、攻撃者は、HTTP 経由のパス トラバーサル攻撃で管理コンソールにアクセスできました。

パッケージは最新のセキュリティ バージョンに更新されました。

サイト管理者が Enterprise 所有者として自動的に追� されないことがありました。

ブランチを既定のブランチにマージした後も、ファイルの [History](履歴) リンクが、ターゲット ブランチではなく、前のブランチにま� リンクしていました。

特定のフィールド (名前など) の値が長すぎた� �合、チェック実行またはチェック スイートを作成または更新すると、500 Internal Server Error (500 内部サーバー エラー) が返されました。

パッケージは最新のセキュリティ バージョンに更新されました。

GitHub Enterprise Server 構成ファイル内のホスト名を検証するための内部スクリプトは、ホスト名の文字列が "." (ピリオド文字) で始まっている� �合、エラーを返しました。

プライマリ ノードのホスト名が 60 文字より長い HA 構成では、MySQL の構成が失敗しました。

--gateway 引数が ghe-setup-network コマンドに追� され、コマンド ラインを使ってネットワーク設定を構成するときに、ゲートウェイ アドレスを渡せるようになりました。

画像添付ファイルが削除された� �合、404 Not Found (404 見つかりません) エラーではなく 500 Internal Server Error (500 内部サーバー エラー) が返されました。

サイト管理者ダッシュボードで� �告される "インスタンス全体の最大コミッター数" の計算が、正しくありませんでした。

GitHub Enterprise Server Backup Utilities を使って復元を実行するとき、リポジトリ レプリカのデータベース エントリが正しくないと、データベースが� �損しました。

クラスター サポート バンドルを生成するときのメトリックの包含を最適化しました。

Elasticsearch が有効な黄色状態を� �告する HA 構成では、前の修正で行われた変更により、ghe-repl-stop コマンドがブロックされ、レプリケーションを停止できません。サービスが通常状態または有効な黄色状態のときに、ghe-repo-stop --force を使うと、Elasticsearch が強制的に停止されるようになります。

中: nginx リゾルバーでセキュリティの問題が見つかりました。DNS サーバーからの UDP パケットを偽� できる攻撃者は、1 バイトのメモリを上書きして、ワーカー プロセスをクラッシュさせたり、損傷を与える可能性がある影響を及ぼすことができました。この脆弱性には、CVE-2021-23017 が割り当てられました。

Git セキュリティ適用ブログ記事で発表された脆弱性に対処するため、actions/checkout@v2 と actions/checkout@v3 アクションを更新しました。

パッケージは最新のセキュリティ バージョンに更新されました。

一部のクラスター トポロジでは、ghe-cluster-status コマンドで /tmp に空のディレクトリが残りました。

SNMP により、多数の Cannot statfs (statfs を実行できません) エラー メッセージが syslog に誤って記録されました。

SAML 認証を使って構成され、組み込みのフォールバックが有効になっているインスタンスでは、組み込みのユーザーがログアウトした後で生成されたページからサインインしようとすると、"ログイン" ループでスタックしていました。

issue コメントにアップロードされたビデオが、適切にレンダリングされませんでした。

SAML で暗号化されたアサーションを使うと、一部のアサーションが SSH キーを検証済みとして正しくマークしませんでした。

ghe-migrator を使うと、issue と pull request のビデオ添付ファイルが、移行でインポートされませんでした。

非 ASCII 文字を含むタグがリポジトリにあると、[Releases](リリース) ページで 500 エラーが返されました。[更新日: 2022-06-10]

高可用性の構成では、管理コンソールのレプリケーション概要ページに、現在のレプリケーション構成� けが表示され、現在のレプリケーション状態は表示されないことが明確化されました。

GitHub Packages を有効にした� �合、接続文字列としての Shared Access Signature (SAS) トークンの使用は現在サポートされていないことに注意してく� さい。

サポート バンドルに、MySQL に� �納されているテーブルの行数が含まれるようになりました。

脆弱性データなしで依存関係グラフを有効にして、使われている依存関係とそのバージョンを確認できるようになりました。GitHub Connect を有効にせずに依存関係グラフを有効にすると、脆弱性情� �は提供されなくなります。

パッケージは最新のセキュリティ バージョンに更新されました。

高可用性のノードをアップグレード パッケージとペアでアップグレードすると、Elasticsearch が不整合な状態になる� �合があります。

一部のクラスター トポロジでは、コマンド ライン ユーティリティ ghe-spokesctl と ghe-btop の実行に失敗する� �合があります。

elasticsearch-upgrade サービスが並行して複数回実行されるため、パッケージのアップグレード時に Elasticsearch インデックスが複製される可能性があります。

ユーザー アカウントを組織に変換したとき、ユーザー アカウントが GitHub Enterprise Server Enterprise アカウントの所有者� った� �合、変換された組織が Enterprise 所有者一覧に誤って表示されます。

Enterprise Administration REST API を使用して権限借用 OAuth トークンを作成すると、OAuth アプリケーション ID に一致する統合が既に存在する� �合、正しく機能しませんでした。

構成適用の実行を停止する構成エラーが、構成ログに� えてターミナルに出力するようになりました。

Memcached で許可される最大値より大きい値をキャッシュしようとすると、エラーが発生しますが、キーは� �告されませんでした。

CodeQL スターター ワークフローで、GitHub Actions の既定のトークン アクセス許可が使われていない� �合でも、エラーが発生しなくなりました。

インスタンスで GitHub Advanced Security 機能が有効になっている� �合、リポジトリ コントリビューションのバッチを処理すると、バックグラウンド ジョブのパフォーマンスが向上します。

中: GitHub Enterprise Server 管理コンソールでパス走査の脆弱性が確認されました。これにより、CSRF 保護のバイパスが可能になりました。この脆弱性により、3.5 より前の GitHub Enterprise Server のすべてのバージョンが影響を受けます。バージョン 3.1.19、3.2.11、3.3.6、3.4.1 で修正されました。この脆弱性は、GitHub バグ� �奨金プログラ� を通じて� �告され、CVE-2022-23732 が割り当てられました。

中: yajil の 1.x ブランチと 2.x ブランチで整数オーバーフローの脆弱性が確認されました。これは、大規模な (2 GB 以下) 入力の処理時に後続のヒープ メモリが� �損する原� になります。この脆弱性は内部的に� �告され、CVE-2022-24795 が割り当てられました。

GitHub Actions が有効にされた� �合、サポート バンドルには機密ファイルが含まれている可能性があります。

パッケージは最新のセキュリティ バージョンに更新されました。

GitHub Enterprise Server をアップグレードした後、古い構成オプションが存在すると、Minio プロセスの CPU 使用率が高くなりました。

以前のリリースでこれらのプロトコル バージョンの削除が行われたにもかかわらず、管理コンソールの [Privacy](プライバシー) 設定の TLS 1.0 と TLS 1.1 を有効にするオプションが表示されていました。

HA 環境では、MSSQL レプリケーションを構成するには、GitHub Actions を初めて有効にした後で追� の手動手� �が必要な� �合がありました。

ホットパッチの後、内部構成ファイルのサブセットの更新がより確実に行われます。

ghe-run-migrations スクリプトでは、一時証明書名の生成が正しく行われない� �合があります。

クラスター環境では、複数の Web ノードにわたる内部 API 呼び出しの失敗とともに、Git LFS 操作が失敗する可能性があります。

syscall 権限が不十分なため、gpg --import を使用する pre-receive フックがタイ� アウトしました。

一部のクラスター トポロジでは、webhook デリバリー情� �が利用できませんでした。

HA 構成では、GitHub Actions が以前に有効にされていた� �合、レプリカの� �棄は失敗します。

Elasticsearch 正常性チェックでは、移行の実行時に黄色のクラスター状態は許可されません。

ユーザーがそのユーザー アカウントを組織に変換した結果として作成された組織は、グローバル Enterprise アカウントに追� されませんでした。

ghe-migrator の使用または GitHub.com からのエクスポート時、長時間実行されているエクスポートは、エクスポートの途中でデータが削除されると失敗します。

保留中のジョブをレンダリングすると、GitHub Actions のデプロイ グラフにエラーが表示されました。

アクセスできないページへのリンクは削除されていました。

Web UI の 2 つのコミットの比較から移動しても、他のページで違いが保持されました。

チー� をレビュー担当者として pull request に追� すると、そのチー� のメンバー数が誤って表示されることがありました。

SCIM グループによって外部で管理されているメンバーを削除しようとすると、Remove team membership for a user (ユーザーのチー�  メンバーシップの削除) API エンドポイントはエラーで応答していました。

休� ユーザーの数が多いと、GitHub Connect 構成の失敗の原� になることがありました。

サイト管理者の Web UI の [Feature & beta enrollments](機能とベータの登録) ページが誤って利用可能になっていました。

サイト フッターの [Site admin mode](サイト管理者モード) リンクをクリックしたとき、状態が変わりませんでした。

spokesctl cache-policy rm コマンドが、error: failed to delete cache policy (エラー: キャッシュ ポリシーを削除できませんでした) というメッセージで失敗しなくなりました。

大規模なクラスター トポロジに対応するために、Memcached 接続制限値が増やされました。

依存関係グラフ API が、以前は静的に定義されたポートを使用して実行されていました。

クラスター関連の Elasticsearch シャード設定の既定のシャード数が更新されました。

"Triage" と "Maintain" チー� のロールは、リポジトリ移行時に保持されます。

Enterprise 所有者によって行われる Web 要求のパフォーマンスが向上しました。

高: 情� �漏洩と RCE につながる可能性のある整数オーバーフローの脆弱性が GitHub の markdown パーサーで確認されました。この脆弱性は、Google の Project Zero の Felix Wilhelm 氏により、GitHub バグ� �奨金プログラ� を通じて� �告され、CVE-2022-24724 が割り当てられました。

高可用性レプリカのクロックがプライマリと同期されていなかった� �合、アップグレードに失敗する� �合があります。

2020 年 9 月 1 日以降に作成された OAuth アプリケーションでは、認可を確認 API エンドポイントを使用することができません。

ユーザーが、"saml" という名前のユーザーまたは組織を登録することができました。

パッケージは最新のセキュリティ バージョンに更新されました。

Azure Blob Storage を使っていると、GitHub Packages のストレージ設定を検証して管理コンソールに保存することができませんでした。

mssql.backup.cadence 構成オプションが、無効な文字の警告で ghe-config-check に失敗しました。

memcached から 2^{^16} を超えるキーを取得した� �合の SystemStackError (スタックが深すぎます) を修正しました。

シークレット スキャンは、ZIP および他のアーカイブ ファイルでのシークレットのスキャンをスキップします。

パッケージは最新のセキュリティ バージョンに更新されました。

MySQL シークレットのローテーションから、nginx を手動で再起動するまで、ページを使用できなくなりました。

GitHub Actions が有効な� �合、移行に失敗することがありました。

ISO 8601 の日付でメンテナンス スケジュールを設定すると、タイ� ゾーンが UTC に変換されないため、実際にスケジュールされる時刻が一致しませんでした。

cloud-config.service に関する誤ったエラー メッセージがコンソールに出力されました。

ghe-cluster-each を使ってホットパッチをインストールした後、バージョン番号が正しく更新されませんでした。

Webhook テーブル クリーンアップ ジョブが同時に実行でき、リソースの競合とジョブ実行時間の増� の原� になっていました。

プライマリからレプリカに対して ghe-repl-teardown を実行しても、MSSQL 可用性グループからそのレプリカが削除されませんでした。

CAS 認証の使用と [一時停止されているユーザーの再アクティブ化] オプションが有効になっていると、一時停止されているユーザーが自動的に再アクティブ化されませんでした。

検証済みまたは承認済みドメインでのメール アドレスを持つユーザーへのメール ベースの通知を制限する機能が、正しく動作しませんでした。

セキュリティ アラート設定に関連するデータベース移行の実行時間が長くなると、アップグレードの完了が遅れることがありました。

GitHub Connect データ接続レコードに、アクティブおよび休� ユーザーの数と構成済みの休� 期間が含まれるようになりました。

パッケージは最新のセキュリティ バージョンに更新されました。これらの更新プログラ� では、Log4j がバージョン 2.17.1 に更新されました。メモ: GitHub Enterprise Server のこれらのバージョンで CVE-2021-44228、CVE-2021-45046、CVE-2021-45105、CVE-2021-44832 の影響に対処するには、以前 3.3.1、3.2.6、3.1.14、3.0.22 でリリースされた軽減策で十分です。

生成されたサポート バンドルでさらに多くのシークレットをサニタイズする

パッケージは最新のセキュリティ バージョンに更新されました。

古い GHES のインストールからアップグレードした後、Actions のセルフホステッド ランナーは自己更新または新しいジョブの実行に失敗しました。

GitHub Packages 用の BLOB ストレージとして MinIO を構成すると、ストレージの設定を検証できませんでした。

/data/user/tmp/pages のアクセス許可の問題が原� で、ghe-config-apply の実行が失敗することがありました。

解像度の低いブラウザーでスクロールすると、管理コンソールの保存ボタンが表示されませんでした。

IOPS と Storage Traffic 監視グラフが、修正されたバージョンのアップグレードの後で更新されませんでした。

一部の Webhook 関連のジョブで、大量のログが生成されることがありました。

複数のドキュメント リンクで、404 Not Found (404 見つかりません) エラーが発生しました。

重大: Log4j ライブラリでのリモート コード実行の脆弱性 (CVE-2021-44228) により、3.3.1 より前の GitHub Enterprise Server のすべてのバージョンが影響を受けました。Log4j ライブラリは、GitHub Enterprise Server インスタンスで実行されるオープンソース サービスで使われます。この脆弱性は、GitHub Enterprise Server バージョン 3.0.22、3.1.14、3.2.6、3.3.1 で修正されました。 詳細については、GitHub ブログのこちらの投稿を参照してく� さい。

2021 年 12 月 17 の更新: このリリースで行われた修正により、このリリースの後で公開された CVE-2021-45046 も軽減されます。CVE-2021-44228 と CVE-2021-45046 の両方を軽減するため、GitHub Enterprise Server の追� のアップグレードは必要ありません。

特定の条件のセットを満たす� �合、サポート バンドルに機密ファイルが含まれることがありました。

GitHub Enterprise Server で、承認時にユーザーに表示されるよりも多くのアクセス許可を GitHub アプリのユーザー認可 Web フロー中に付与できるという UI 偽装の脆弱性が確認されました。この脆弱性は、3.3 より前のすべてのバージョンの GitHub Enterprise Server に影響があり、バージョン 3.2.5、3.1.13、3.0.21 で修正されました。この脆弱性は、GitHub バグ� �奨金プログラ� を通じて� �告され、CVE-2021-41598 が割り当てられました。

GitHub Pages のサイトをビルドする際に悪用される可能性があるリモート コード実行の脆弱性が、GitHub Enterprise Server で見つかりました。この脆弱性は、3.3 より前のすべてのバージョンの GitHub Enterprise Server に影響を与え、バージョン 3.0.21、3.1.13、3.2.5 で修正されました。この脆弱性は、GitHub バグ� �奨金プログラ� を通じて� �告され、CVE-2021-41599 が割り当てられました。2022 年 2 月 17 日に更新されました。

Actions が有効になっていない� �合、ghe-support-bundle により、Unable to find MS SQL container (MS SQL コンテナーが見つかりません) という予期しないメッセージが� �告されていました。

/data/user/tmp/pages のアクセス許可の問題が原� で、ghe-config-apply の実行が失敗することがありました。

管理コンソールでの構成ミスにより、スケジュール エラーが発生しました。

ログのローテーションの後、Docker がログ ファイルを開いたままにしていました。

UTF-8 互換ではない blob_path 値の処理が不適切なため、移行がスタックすることがありました。

GraphQL の要求で、pre-receive フック環境の GITHUB_USER_IP 変数が設定されていませんでした。

組織の監査ログの改ページ位置の自動修正リンクにクエリ パラメーターが保持されていませんでした。

ホットパッチ中に切り替えが複数回実行されると、ハッシュが重複することがありました。

ドキュメントの Actions パス スタイルの説明をわかりやすくしました。

現在のサポート サイト support.github.com を使うように、サポート連絡先の URL を更新しました。

ghe-mssql-diagnostic を実行したときの追� のトラブルシューティングが提供されました。

パッケージは最新のセキュリティ バージョンに更新されました。

GitHub Actions が有効になっているとき、ghe-repl-start または ghe-repl-status を実行すると、データベースへの接続に関するエラーが返されることがありました。

PATH が定義されていないため、pre-receive フックが失敗しました。

インスタンスが以前にレプリカとして構成されていた� �合、ghe-repl-setup を実行すると、cannot create directory /data/user/elasticsearch: File exists (ディレクトリ /data/user/elasticsearch を作成できません: ファイルが存在します) というエラーが返されました。

ghe-support-bundle を実行すると、integer expression expected (整数式が必要です) というエラーが返されていました。

高可用性レプリカを設定した後は、ghe-repl-status の出力に unexpected unclosed action in command (コマンドで予期せずクローズされなかったアクション) というエラーが含まれていました。

大規模なクラスター環境では、フロントエンド ノードのサブセットで、認証バックエンドを利用できませんでした。

一部の重要なサービスが、GHES クラスターのバックエンド ノードで利用できない可能性があります。

ユーザーに対して /repos API で返されるリポジトリ アクセス許可で、完全なリストが返されませんでした。

一部の状況では、GraphQL スキーマの Team オブジェクトの childTeams 接続により、正しくない結果が生成されていました。

高可用性構成で、リポジトリのメンテナンスが成功した� �合でも、stafftools で常に失敗と表示されていました。

ユーザー定義パターンにより、package.json や yarn.lock のようなファイル内のシークレットが検出されませんでした。

ghe-cluster-suport-bundle でクラスター サポート バンドルを作成するときの、gzip 圧縮の追� 外部レイヤーが、既定でオフにされるようになりました。この外側の圧縮は、必要に応じて、ghe-cluster-suport-bundle -c コマンド ライン オプションで適用できます。

エクスペリエンス向上のためのモバイル アプリのデータ収集についてユーザーに注意を促す追� のテキストを、管理者コンソールに追� しました。

GitHub Connect のデータ接続レコードに、有効になっている GitHub Connect 機能のリストが含まれるようになりました。[2021-12-09 更新]

GitHub Enterprise Server の GitHub Pages のビルドで、攻撃者によるシステ�  ファイルの読み取りを可能にするパス トラバーサルの脆弱性が見つかりました。攻撃者がこの脆弱性を悪用するには、GitHub Enterprise Server インスタンス上に GitHub Pages サイトを作成してビルドするためのアクセス許可が必要です。GitHub Enterprise Server の 3.3 より前のすべてのバージョンがこの脆弱性による影響を受け、バージョン 3.0.19、3.1.11、3.2.3 で修正されました。この脆弱性は、GitHub Bug Bounty プログラ� によって� �告され、CVE-2021-22870 を割り当てられました。

パッケージは最新のセキュリティ バージョンに更新されました。

HAProxy の構成のため、GitHub Enterprise Server 3.x クラスターをアップグレードした後、Git の一部の操作が失敗しました。

クラスタリング モードでは、Unicorn ワーカーの数が正しく設定されないことがありました。

クラスタリング モードでは、Resqued ワーカーの数が正しく設定されないことがありました。

Ubuntu の Uncomplicated Firewall (UFW) の状態が非アクティブの� �合、クライアントはそのことをログに明確に表示できませんでした。

LDAP の構成に UTF8 文字が含まれている� �合、GitHub Enterprise Server 2.x から 3.x へのアップグレードが失敗しました。

特定のクラスター構成のクラスター モードでは、一部のページおよび Git 関連のバックグラウンド ジョブが実行しない� �合がありました。

Server Statistics のドキュメントのリンクが壊れていました。

新しいタグが作成されたとき、プッシュ Webhook のペイロードに正しい head_commit オブジェクトが表示されませんでした。現在は、新しいタグが作成されると、プッシュ Webhook のペイロードに、新しいタグが指すコミットのデータを含む head_commit オブジェクトが常に含まれるようになりました。その結果、head_commit オブジェクトには常にペイロードの after コミットのコミット データが含まれるようになります。

Enterprise の監査ログのページに、secret scanning の監査イベントが表示されませんでした。

ジョブのタイ� アウトが、レプリカの修復に対して十分ではありませんでした。

リポジトリのリリース ページでリリースを表示すると、500 エラーが返りました。

ユーザーがファイルを表示するとき、危険性がある双方向 Unicode 文字に関する警告が表示されませんでした。詳しくは、the GitHub Blog の「双方向 Unicode テキストに関する警告」をご覧く� さい。

Hookshot Go が、Collectd で処理できない分散の種類のメトリックを送信しており、解析のバルーニング エラーが発生しました。

パブリック リポジトリで、secret scanning から Unknown Token (不明トークン) の種類で予期しない結果が表示されました。

Kafka の構成の改善が追� されました。リポジトリを削除するとき、� �域を解放するため、パッケージ ファイルがストレージ アカウントからすぐに削除されるようになりました。DestroyDeletedPackageVersionsJob で、メタデータ レコードと共に古いパッケージのパッケージ ファイルがストレージ アカウントから削除されるようになりました。

クリア テキストのパスワードが特定のログ ファイルに� �納される可能性がありました。

複数の既知の脆弱な SSH 公開キーが拒否リストに追� されており、登録できなくなっています。さらに、脆弱な SSH 公開キーを生成することが知られている GitKraken のバージョン (7.6.x、7.7.x、8.0.0) が、新しい公開キーの登録からブロックされるようになりました。

パッケージは最新のセキュリティ バージョンに更新されました。

オーケストレーターが正常でない� �合、クラスタリング モードでのエンタープライズ サーバーの復元が失敗することがありました。

codespace のリンクが組織の設定に表示されていました。

多くの組織の所有者であるユーザーが、アプリケーションの複数の部分を利用できませんでした。

https://docs.github.com へのリンクを修正しました。

多くの参照を含むリポジトリに関する閲覧とジョブのパフォーマンスの最適化。

パッケージが最新のセキュリティ バージョンに更新されました。

カスタ� の pre-receive フックが、仮想メモリの制限が厳しすぎる、または CPU 時間の制限のために失敗した可能性があります。

GitHub Enterprise Server クラスタリング構成で、依存関係グラフの設定が正しく適用されないことがありました。

ghe-cleanup-settings を使用した既存のすべての構成設定のワイプの試行により、管理コンソール サービスの再起動に失敗しました。

ghe-repl-teardown を使用したレプリケーションの� �棄時に Memcached の再起動に失敗しました。

� 荷が高いとき、アップストリー�  サービスで内部の正常性チェックに失敗した� �合、ユーザーは HTTP 503 状態コードを受け取ります。

pre-receive フック環境では、Alpine で BusyBox を介して cat コマンドを呼び出すことが禁止されていました。

プライマリ クラスター データセンターからセカンダリ クラスター データセンターへのフェールオーバーに成功しましたが、元のプライマリ クラスター データセンターへのフェールバックで、Elasticsearch インデックスの昇� �に失敗しました。

Organization の Team ページの [チー� のインポート] ボタンで、HTTP 404 が返されました。

API を使って Secret Scanning を無効にすると、プロパティは正しく無効になりますが、HTTP 422 とエラー メッセージは正しく返されませんでした。

GitHub Enterprise 管理者が [Dormant users](休� ユーザー) ページを表示しようとしたときに、502 Bad Gateway (502 無効なゲートウェイ) または 504 Gateway Timeout (504 ゲートウェイ タイ� アウト) の応答を受け取ることがありました。

SynchronizePullRequestJob ジョブの数が増� したことにより、特定の� 荷の高い状況でパフォーマンスに悪影響がありました。

Secret Scanning 用に作成されたユーザー定義パターンが、削除後も引き続きスキャンされていました。

GitHub アプリは、API と同様にリポジトリ上で Secret Scanning 機能を設定するようになりました。

GitHub Advanced Security customers can now specify custom patterns for secret scanning. When a new pattern is specified, secret scanning searches a repository's entire Git history for the pattern, as well as any new commits.

User defined patterns are in beta for GitHub Enterprise Server 3.2. They can be defined at the repository, organization, and enterprise levels. For more information, see "Defining custom patterns for secret scanning."

GitHub Advanced Security customers now have an organization-level view of the application security risks detected by code scanning, Dependabot, and secret scanning. The security overview shows the enablement status of security features on each repository, as well as the number of alerts detected.

In addition, the security overview lists all secret scanning alerts at the organization level. Similar views for Dependabot and code scanning alerts are coming in future releases. For more information, see "About the security overview."

GitHub Advanced Security customers can now see a rich diff of the dependencies changed in a pull request. Dependency review provides an easy-to-understand view of dependency changes and their security impact in the "Files changed" tab of pull requests. It informs you of which dependencies were added, removed, or updated, along with vulnerability information for these dependencies. For more information, see "Reviewing dependency changes in a pull request."

Environments, environment protection rules, and environment secrets are now generally available for GitHub Actions on GitHub Enterprise Server. For more information, see "Environments."

SSH authentication using a FIDO2 security key is now supported when you add a sk-ecdsa-sha2-nistp256@openssh.com or sk-ssh-ed25519@openssh.com SSH key to your account. SSH security keys store secret key material on a separate hardware device that requires verification, such as a tap, to operate. For more information, see "Generating a new SSH key and adding it to the ssh-agent."

Dark and dark dimmed themes are now available for the web UI. GitHub Enterprise Server will match your system preferences when you haven't set theme preferences in GitHub Enterprise Server. You can also choose which themes are active during the day and night. For more information, see "Managing your theme settings."

Domains that are not able to be verified can now be approved for email notification routing. Enterprise and organization owners will be able to approve domains and immediately augment their email notification restriction policy, allowing notifications to be sent to collaborators, consultants, acquisitions, or other partners. For more information, see "Verifying or approving a domain for your enterprise" and "Restricting email notifications for your enterprise."

Git Credential Manager (GCM) versions 2.0.452 and later now provide security-hardened credential storage and multi-factor authentication support for GitHub Enterprise Server.

GCM with support for GitHub Enterprise Server is included with Git for Windows versions 2.32 and later. GCM is not included with Git for macOS or Linux, but can be installed separately. For more information, see the latest release and installation instructions in the GitCredentialManager/git-credential-manager repository.

A 'User Agent Referrer Policy' setting has been added to the enterprise settings. This allows an admin to set a stricter Referrer-Policy to hide the hostname of a GitHub Enterprise Server installation from external sites. The setting is disabled by default and is tracked by audit log events for staff and enterprise owners when enabled or disabled. For more information, see "Configuring Referrer Policy for your enterprise."

The MySQL health check was changed to use mysqladmin ping instead of TCP checks, which removes some unnecessary noise in the MySQL error log. Also, Orchestrator failover checks were improved to prevent unnecessary MySQL failovers when applying cluster config changes.

The Resque service, which supports background job processing, has been replaced with Aqueduct Lite. This change makes the job system easier to manage and should not affect the user experience. For the new administration and debugging commands for Aqueduct, see "Command-line utilities."

The format of authentication tokens for GitHub Enterprise Server has changed. The change affects the format of personal access tokens and access tokens for OAuth Apps, as well as user-to-server, server-to-server, and refresh tokens for GitHub Apps.

The different token types now have unique identifiable prefixes, which allows for secret scanning to detect the tokens so that you can mitigate the impact of someone accidentally committing a token to a repository. GitHub recommends updating existing tokens as soon as possible. For more information, see "About authentication to GitHub" and "About secret scanning."

Repositories on user profiles and organization profiles now support sorting by star count.

When viewing the commit history of a single file, you can now click to view that file at the selected point in history.

When a submodule is defined with a relative path in your GitHub Enterprise Server instance, the submodule is now clickable in the web UI. Clicking the submodule in the web UI will take you to the linked repository. Previously, only submodules with absolute URLs were clickable. This is supported for relative paths for repositories with the same owner that follow the pattern ../REPOSITORY or relative paths for repositories with a different owner that follow the pattern ../OWNER/REPOSITORY. For more information about working with submodules, see Working with submodules on the GitHub Blog.

The web UI can now be used to synchronize an out-of-date branch of a fork with the fork's upstream branch. If there are no merge conflicts between the branches, the branch is updated either by fast-forwarding or by merging from upstream. If there are conflicts, you will be prompted to create a pull request to resolve the conflicts. For more information, see "Syncing a fork."

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."

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 the GitHub Blog.

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."

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 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 about the new performance targets for a range of CPU and memory configurations, see "Getting started with GitHub Actions for GitHub Enterprise Server."

• The "Maximum Concurrency" values were modified to reflect our most up to date performance testing. [Updated: 2021-12-07]

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

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".

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 alerts 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 alerts 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 Dependabot alerts" and "Managing alerts from secret scanning."

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."

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."

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 "Commits" 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.

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.

GitHub Advanced Security をご利用のお客様が GitHub Enterprise Server 3.5 以降にアップグレードした� �合、Web UI と REST API でシークレット スキャンからのアラートが表示されなくなることがあります。 以前と同様にアラートが表示されるようにするには、以前のリリースから 3.5 以降にアップグレードするときに 3.4 をスキップしないでく� さい。 修正プログラ� は、3.5.5 および 3.6.1 パッチ リリースで入手できます。

3.4 を介したアップグレードを計画する� �合は、アップグレード アシスタントに関する記事を参照してく� さい。 [更新日: 2022-09-01]

GitHub Enterprise Server 2.21 was discontinued on June 6, 2021. That means that no patch releases will be made, even for critical security issues, after this date. For better performance, improved security, and new features, upgrade to the newest version of GitHub Enterprise Server as soon as possible.

GitHub Enterprise Server 2.22 will be discontinued on September 23, 2021. That means that no patch releases will be made, even for critical security issues, after this date. For better performance, improved security, and new features, upgrade to the newest version of GitHub Enterprise Server as soon as possible.

Beginning in GitHub Enterprise Server 3.1, we will begin discontinuing support for Xen Hypervisor. The complete deprecation is scheduled for GitHub Enterprise Server 3.3, following the standard one year deprecation window. Please contact GitHub Support with questions or concerns.

GitHub Enterprise Server 3.2 removes unused GitHub Service database records. More information is available in the deprecation announcement post.

To prevent accidental logging or exposure of access_tokens, we discourage the use of OAuth Application API endpoints and the use of API auth via query params. Visit the following posts to see the proposed replacements:

• Replacement OAuth Application API endpoints
• Replacement auth via headers instead of query param

These endpoints and auth route are planned to be removed from GitHub Enterprise Server in GitHub Enterprise Server 3.4.

Two legacy GitHub Apps-related webhook events have been removed: integration_installation and integration_installation_repositories. You should instead be listening to the installation and installation_repositories events.

The following REST API endpoint has been removed: POST /installations/{installation_id}/access_tokens. You should instead be using the namespaced equivalent POST /app/installations/{installation_id}/access_tokens.

GitHub Connect will no longer work after June 3rd for instances running GitHub Enterprise Server 3.1 or older, due to the format of GitHub authentication tokens changing. To continue using GitHub Connect, upgrade to GitHub Enterprise Server 3.2 or later. For more information, see the GitHub Blog. [Updated: 2022-06-14]