Enterprise Server 3.5 release notes

高: 2.39.2 からの修正 (CVE-2023-22490 と CVE-2023-23946 に対処する) を含むように Git を更新しました。

中: 2.40.1 からの修正を含むように Git を更新しました。 詳しくは、GitHub ブログの「発表された Git セキュリティの脆弱性」を参照してください。

ユーザーは、Issue または Pull Request のコメント内で GIF ファイルを添付ファイルとしてアップロードできませんでした。

サイト管理者は、IANA の登録済みトップレベル ドメイン (TLD) またはインスタンスの例外リストのトップレベル ドメイン (TLD) のプロキシをバイパスできませんでした。

一部のプラットフォームでは、管理 SSH アクセス権を持つユーザーが ghe-diagnostics を実行した後、コマンドの出力に表面的な SG_IO エラーが含まれていました。

削除された Organization の復元後、その Organization はインスタンスの Organization のリストに表示されませんでした。

サイト管理者が GitHub Enterprise Importer を使用して GitHub Enterprise Cloud からデータをインポートしたときに、ファイルレベルのコメントのインポート中に移行が失敗しました。 この失敗により、インポートが続行されなくなります。

サイト管理者が GitHub Enterprise Importer を使用したときに、リポジトリ内のプロジェクト列にアーカイブされたカードが 2,500 枚以上含まれていた場合、リポジトリのインポートに失敗しました。

ブランチ保護が存在したとき、GITHUB_REF_PROTECTED 環境変数と github.ref_protected コンテキストが false と正しく設定されませんでした。

UTC より大きいタイムゾーンに対しても構成された GitHub Advanced Security ライセンスがあるインスタンスでは、ユーザーがシークレットを降順で日付順に並べ替えた場合、シークレット スキャン アラートのリストに "シークレットの読み込みに失敗しました" というエラーが表示されました。

ghe-support-bundle または ghe-cluster-support-bundle ユーティリティを使ってサポート バンドルを生成する管理 SSH アクセス権を持つユーザーは、スペースや引用符を使用せずに -p または --period でデータを収集する期間を指定できます。 たとえば、'-p 5 days' または -p '4 days 10 hours' に加え、-p 5days または -p 4days10hours が有効です。

In some cases, graphs on the Management Console's monitor dashboard failed to render.

On an instance with GitHub Connect enabled, if "Users can search GitHub.com" was enabled, issues in private and internal repositories were not included in users search results for GitHub.com.

To avoid a failure during a configuration run on a cluster, validation of cluster.conf with the ghe-cluster-config-check utility ensures that the consul-datacenter field for each node matches the top-level primary-datacenter field.

If a site administrator provides an invalid configuration for blob storage for GitHub Actions or GitHub Packages on an instance, the preflight checks page displays details and troubleshooting information.

高: SSH 証明機関経由で認証することで不正なアクターが他のユーザーのシークレット gist を変更できるという不適切な認証の脆弱性に対処しました。 この脆弱性は  GitHub バグ報奨金プログラム を通じて報告され、 CVE-2023-23761 が割り当てられています。 [更新日: 2023 年 4 月 7 日]

中: 誤った差分を表示することでコミットを密輸できるという誤った比較の脆弱性に対処しました。 この脆弱性は  GitHub バグ報奨金プログラム を通じて報告され、 CVE-2023-23762 が割り当てられています。 [更新日: 2023 年 4 月 7 日]

管理コンソールのモニター ダッシュボードでは、git fetch catching コマンドで取得された Cached Requests と Served Requests グラフに、インスタンスのメトリックが表示されませんでした。

サイト管理者が ghe-config app.github.rate-limiting-exempt-users "github-actions[bot]" コマンドを使用して @github-actions[bot] ユーザーをレート制限から除外した後、ghe-config-check を実行すると、Validation is-valid-characterset failed 警告が表示されました。

GitHub Actions (actions) と Microsoft SQL (mssql) が、インスタンスのモニター ダッシュボード内のプロセス リストに表示されませんでした。

管理者が /setup/api/start REST API エンドポイントを使用してライセンスをアップロードした後、移行フェーズ中に構成の実行が Connection refused エラーで失敗しました。

高可用性構成のインスタンスで、管理者が ghe-repl-setup を実行した直後 (ただし、ghe-repl-start の前) に ghe-repl-teardown を使用してレプリカ ノードからレプリケーションを破棄した場合、スクリプトが cannot launch /usr/local/bin/ghe-single-config-apply - run is locked であることを示すエラーが示されました。 ghe-repl-teardown では、情報アラートが表示され、破棄が続けられるようになりました。

クラスター構成のインスタンスで、サイト管理者が ghe-maintenance -s を使用してメンテナンス モードを設定するときに、ユーティリティによる /data/user/common/cluster.conf へのアクセスの試行時に Permission denied エラーが表示されました。

高可用性の構成中に、サイト管理者が ghe-repl-start ユーティリティを中断した場合、このユーティリティによって、レプリケーションが構成されたことが誤って報告され、期待されるクリーンアップ操作がインスタンスによって実行されませんでした。

サイト管理者が GitHub Enterprise Server へのデータの移行に ghe-migrator を使用したときに、場合によっては、チームのインポート後に入れ子になったチームのリレーションシップが保持されませんでした。

リポジトリに CODEOWNERS ファイルが含まれていた場合、そのリポジトリ内の pull request で断続的にファイルの有効性や更新されたコード所有者情報を表示できなかったので、ユーザーはページを再読み込みする必要がありました。

サイト管理者ダッシュボードから利用できる、すべてのユーザーとすべてのアクティブ ユーザーの CSV レポートでは、SSH または個人用アクセス トークンを使用した最近のアクセスは考慮されませんでした。

GitHub Connect が有効になっているインスタンスで、[ユーザーが GitHub.com を検索できる] が有効になっていた場合、ユーザーには GitHub.com の検索結果でプライベートと内部リポジトリの Issue が示されませんでした。

GitHub Enterprise Server により、collectd で処理できないディストリビューション メトリックが発行されていました。 そのメトリックには、pre_receive.lfsintegrity.dist.referenced_oids、pre_receive.lfsintegrity.dist.unknown_oids、git.hooks.runtime が含まれていました。

Enterprise 所有者が Dependabot の更新プログラムを有効にした後、インスタンスによる更新プログラムの初期セットの作成がより迅速に行われるようになります。

クラスター構成のインスタンスで、サイト管理者が ghe-maintenance -s を使用して単一のクラスター ノードにメンテナンス モードを設定すると、ユーティリティによって、すべてのクラスター ノードでメンテナンス モードを設定するために ghe-cluster-maintenance -s を使用するように管理者に警告されます。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。

サイト管理者が GitHub Enterprise Server の送信 Web プロキシ サーバーを構成するときに、プロキシ構成から除外されたトップレベル ドメイン (TLD) がインスタンスで検証されるようになりました。 既定では、IANA で指定されるパブリック TLD を除外できます。 サイト管理者は、ghe-config を使用して除外する未登録の TLD のリストを指定できます。 どのパブリック TLD でも . プレフィックスは必須です。 たとえば、.example.com は有効ですが、example.com は無効です。 詳しくは、「アウトバウンドの Web プロキシ サーバーの設定」を参照してください。

複数のノードがあるインスタンスに対する Git 操作の成功に関する断続的な Issue を回避するために、GitHub Enterprise Server により、SQL クエリを試行する前に MySQL コンテナーの状態が確認されます。 タイムアウト期間も短縮されました。

ghe-saml-mapping-csv -d からの出力の既定のパスは、/tmp ではなく /data/user/tmp です。 詳しくは、「コマンド ライン ユーティリティ」を参照してください。

高: GitHub Pages のサイトをビルドするときにリモート コードの実行を許可するパス トラバーサルの脆弱性が、GitHub Enterprise Server で特定されました。 この脆弱性を悪用するために、攻撃者は GitHub Enterprise Server インスタンス上に GitHub Pages サイトを作成してビルドするアクセス許可を必要とします。 この脆弱性は GitHub バグ報奨金プログラムを通じて報告され、CVE-2023-23760 が割り当てられています。 [更新日: 2023 年 3 月 10 日]

ユーザー アカウントにログインしているデバイスで開いているセッションの一覧を表示すると、GitHub Enterprise Server Web UI に正しくない場所が表示される可能性があります。

まれに、Elasticsearch のプライマリ シャードがレプリカ ノードにある場合、ghe-repl-stop コマンドは ERROR: Running migrations で失敗します。

高: 2.39.2 からの修正 (CVE-2023-22490 と CVE-2023-23946 に対処する) を含むように Git を更新しました。

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

GitHub パッケージの AWS S3 URL として VPC エンドポイントの URL を使うと、パッケージの発行とインストールが失敗しました。

中: GitHub Enterprise Server でコード インジェクションの脆弱性が特定されました。この脆弱性により、null バイトの不適切なサニタイズが原因で、Windows ベースのランナーを使う場合に GitHub Actions の 1 つの環境変数値から任意の環境変数を設定できます。 攻撃者がこの脆弱性を悪用するには、GitHub Actions で使う環境変数の値を制御するための既存のアクセス許可が必要です。 この脆弱性は、GitHub バグ報奨金プログラムを通じて報告され、CVE-2023-22381 が割り当てられています。

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

構成の実行の検証フェーズ中に、Notebook と Viewscreen のサービスで No such object error が発生している可能性があります。

Let's Encrypt で TLS 証明書の自動管理を有効にすると、エラー The certificate is not signed by a trusted certificate authority (CA) or the certificate chain in missing intermediate CA signing certificates でプロセスが失敗する可能性があります。

差分生成中にタイムアウトが発生した場合 (たとえば、差分生成に時間がかかりすぎているというエラーがコミットで表示された場合など)、push Webhook イベントは空の差分情報を配信します。 以前は、push Webhook イベントの配信は失敗していました。

高: 2.39.1 からの修正 (CVE-2022-41903 と CVE-2022-23521 に対処します) を含むように Git を更新しました。

サポート バンドルと構成ログで追加のシークレットをサニタイズします。

CodeQL アクションの依存関係が最新のセキュリティ バージョンに更新されました。

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

github (メタデータから名前が変更されました)、gitauth、unicorn コンテナー サービス用の Active workers と Queued requests のメトリックが、collectd から正しく読み込まれず、管理コンソールに表示されませんでした。

Dependabot のアラート メールが、無効なリポジトリに送信されました。

移行用にロックされたリポジトリを使用すると、Web UI でファイルを編集できます。

変更の間に多数の行がある大きなファイルに対する pull request の差分を表示すると、すべての変更が表示されるようにビューを展開できませんでした。

git-janitor コマンドが古い multi-pack-index.lock ファイルを修正できなかったため、リポジトリのメンテナンスに失敗しました。

ghe-support-bundle と ghe-cluster-support-bundle コマンドは、時間制約付きサポート バンドルを生成するための -p/--period フラグが含まれるように更新されました。 期間は、日数と時間単位で指定できます (例: -p '2 hours'、-p '1 day'、-p '2 days 5 hours')。

ghe-config-apply で開始された構成実行のパフォーマンスが向上しました。

新しいルート パーティションを使用してインスタンスをアップグレードする場合、-t/--target オプションを指定して ghe-upgrade コマンドを実行すると、ターゲット パーティションに対して最小ディスク ストレージ サイズのプレフライト チェックが確実に実行されます。

アカウント データのエクスポート、リポジトリのバックアップ、または移行の実行時に、リポジトリ アーカイブへのリンクは 1 時間後に期限が切れるようになりました。 以前は、アーカイブ リンクは 5 分後に期限切れになっていました。

高: GitHub Pages のサイトをビルドするときにリモート コードの実行を許可するパス トラバーサルの脆弱性が、GitHub Enterprise Server で特定されました。 攻撃者がこの脆弱性を悪用するには、インスタンス上に GitHub Pages サイトを作成してビルドするためのアクセス許可が必要です。 この脆弱性は、GitHub バグ報奨金プログラムを通じて報告され、CVE-2022-46256 が割り当てられました。

高: 不正な承認の脆弱性により、スコープ付きユーザーからサーバーへのトークンが、リポジトリの完全な管理者アクセスにエスカレートするおそれがありました。 攻撃者が悪意のある GitHub アプリをインストールするには、管理者アクセス権を持つアカウントが必要でした。 GitHub Enterprise Server 3.7.0 より前のすべてのバージョンが、この脆弱性の影響を受けました。 この脆弱性は、GitHub バグ報奨金プログラムを通じて報告され、CVE-2022-23741 が割り当てられました。

中: GitHub Enterprise Server で情報漏えいの脆弱性が特定されました。この脆弱性により、プライベート リポジトリにアクセスできないユーザーがこのリポジトリを API 経由で GitHub Actions ランナー グループに追加することができ、その結果、そのリポジトリの名前が UI に表示されます。 攻撃者がこの脆弱性を悪用するには、GHES インスタンスへのアクセス権と GitHub Actions ランナー グループを変更するためのアクセス許可を得る必要があることに加え、プライベート リポジトリの難読化された ID を解読する必要があります。 この脆弱性は、GitHub バグ報奨金プログラムを通じて報告され、CVE-2022-46257 が割り当てられています。

GitHub Actions の依存関係で固定された SHA バージョンが使われている場合、Dependabot は依存関係を脆弱としてマークしなくなります。

サイト管理者が管理シェル (SSH) を使ってインスタンスのプライマリ ノードから ghe-repl-sync-ca-certificates コマンドを実行すると、コマンドはインスタンスのプライマリ ノードから単一のレプリカ ノードにのみ CA 証明書をレプリケートしました。 このコマンドでは、使用可能なすべてのレプリカ ノードに証明書がレプリケートされませんでした。

無効な容量値を持つ OVA ファイルが生成されたため、VMware ESXi ハイパーバイザーへの GitHub Enterprise Server のインストールが失敗しました。

ユーザーが API を使って操作を実行すると、グローバルに無効になっている場合でも、GitHub Enterprise Server によってリポジトリ サイズクォータが適用されました。

member Webhook イベントに、changes フィールドの一部として permission フィールドに対する from と to フィールドの値が含まれませんでした。

ユーザーのアカウントがインスタンスから削除された後、ユーザーがコメントでアップロードした画像添付ファイルが Web インターフェイスに表示されなくなりました。

場合によっては、コード スキャンを設定するためのページで、GitHub Actions がインスタンスに対して構成されていないことが誤って報告されました。

新しい Gist の作成時にユーザーが複数のファイルをアップロードした場合、ユーザーは最初のものの後でアップロードしたファイルを削除できませんでした。

デバッグ レベルのメッセージがシステム ログに表示され、インスタンスのルート ストレージ ボリュームの領域が急速に消費されることがありました。

中: Markdown REST API への並列要求によって無制限のリソース枯渇が発生するおそれがあるシナリオに対処するために CommonMarker を更新しました。 この脆弱性には、CVE-2022-39209 が割り当てられました。

中: GitHub Apps からスコープ指定されたユーザーからサーバーへのトークンは、リポジトリ以外のリソースにアクセスするときに GraphQL API 要求の認可チェックをバイパスする可能性があります。 この脆弱性は、GitHub バグ報奨金プログラムを通じて報告され、CVE-2022-23739 が割り当てられました。

中: pull request プレビュー リンクにより URL が適切にサニタイズされなかったため、悪意のあるユーザーがインスタンスの Web UI に危険なリンクを埋め込むことができるようになっていました。 この脆弱性は、GitHub バグ報奨金プログラムを通じて報告されました。

中: GitHub Enterprise Server で不正な認可の脆弱性が特定されました。これにより、読み取りおよび書き込みアクセス権を持つリポジトリ スコープのトークンが、ワークフロー スコープなしで GitHub Actions ワークフロー ファイルを変更することができました。 「リポジトリコンテンツ」はワークフロー スコープを適用する必要があります。 この脆弱性は、GitHub バグ報奨金プログラムを通じて報告され、CVE-2022-46258 が割り当てられました。

IP 例外リストを使用したメンテナンス モードの設定が、アップグレード後に保持されませんでした。

GitHub Pages のビルドが、高可用性用に構成された AWS のインスタンスでタイムアウトする場合がありました。

Dependabot とアラート ダイジェスト メールを構成した後、インスタンスによって一時停止されているユーザーにダイジェスト メールが送信されます。

Dependabot アラート イベントの監査ログ タイムスタンプにより、ユーザーがアラートに対してアクションを実行したときにタイムスタンプではなく、アラートの作成日が返されました。

プロキシの背後からインスタンス JavaScript リソースにアクセスすると、ブラウザーにクロスオリジン リソース共有 (CORS) エラーが表示されました。

ユーザーが状態チェックに先頭または末尾にスペースを含む名前を付けた場合、インスタンスにより、同じ名前で先頭または末尾のスペースがない別のチェックが存在するかどうかの重複チェックが作成されました。

ユーザーが複数のリポジトリに対して pre-receive フックを構成した場合、インスタンスの Hooks ページにフックの正しい状態が表示されない場合がありました。

エンタープライズ所有者がユーザーの権限を借用して GitHub アプリをインストールしようとすると、インストールを確認するボタンが無効になっていて、クリックできませんでした。

高可用性向けに構成されたインスタンスで GitHub Enterprise Importer の移行を実行した後、移行ストレージ資産のレプリケーションが追いつかない場合がありました。

ゾンビ プロセスが gitrpcd コンテナーに蓄積されなくなりました。

高: 管理コンソールの依存関係を最新のパッチ バージョンに更新しました。これは、CVE-2022-30123 や CVE-2022-29181 などのセキュリティ脆弱性に対処します。

高: 不正なアクターがパブリック リポジトリを介してプライベート リポジトリ ファイルにアクセスするのを許してしまう不適切なキャッシュ キーの脆弱性に対処するためのチェックを追加しました。 この脆弱性には、CVE-2022-23738 が割り当てられました。

中: Markdown REST API への並列要求によって無制限のリソース枯渇が発生する可能性があるシナリオに対処するために 、CommonMarker を更新しました。 この脆弱性には、CVE-2022-39209 が割り当てられました。

中: CVE-2021-32672 と CVE-2021-32762 に対処するため、Redis を 5.0.14 に更新しました。

中: GitHub Actions ジョブの環境変数が変数のコンテキストをエスケープするのを許すバグを修正し、docker コマンドの直接呼び出しを変更するため、GitHub Actions ランナーを更新しました。 詳しくは、Actions ランナーのセキュリティ アドバイザリに関する記事をご覧ください。

中: 不適切な特権を持つユーザーが API を使ってページを作成または削除するのを許す不適切な特権管理の脆弱性が GitHub Enterprise Server で見つかりました。 この脆弱性を悪用するには、攻撃者は書き込みアクセス許可を持つ組織のリポジトリに追加される必要があります。 この脆弱性は、GitHub バグ報奨金プログラムを通じて報告され、CVE-2022-23737 が割り当てられました。

低: CSRF の脆弱性により、インスタンスの site/toggle_site_admin_and_employee_status エンドポイントに対する GET 要求によって、ユーザーのサイト管理者の状態が知らないうちに切り替えられる可能性がありました。

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

サイト管理者が構成の実行 (GitHub Actions の無効化など) をトリガーする変更を行った後、サービスの検証がメッセージ WARNING: Validation encountered a problem で失敗することがありました。

サイト管理者が、JavaScript のファイルやイメージなどの Web インターフェイス アセットへの変更を含むホットパッチをインストールした後、インスタンスで新しいアセットが提供されませんでした。

Git を使用して名前が変更されたリポジトリにユーザーがアクセスすると、Git 出力のホスト名で、インスタンスのホスト名ではなく、GitHub.com が誤って示されました。

LDAP 認証と LDAP 同期を使うインスタンスでは、同期が失敗し、ldap-sync.log に undefined method ord for nil:NilClass が出力されました。

リポジトリのタグ保護状態を作成するためのエンドポイントが 500 エラーを返していたバグに対処しました。

削除された資産と、リポジトリ内で消去されるようにスケジュールされた資産 (LFS ファイルなど) のクリーンアップに時間がかかりすぎました。

ユーザーがユーザー アカウントに GitHub アプリをインストールした後、そのアカウントを Organization に変換した場合、アプリに Organization のアクセス許可が付与されませんでした。

GitHub Enterprise Server 3.4 に直接アップグレードされなかった GitHub Advanced Security ライセンスを使用するインスタンスで表示されないシークレット スキャン アラートが、Web インターフェイスと REST API で表示されるようになりました。

場合によっては、GitHub Advanced Security ライセンスがあるインスタンスで、シークレット スキャン アラートにプロバイダーの種類が含まれず、代わりにプロバイダーの種類として "不明" が示されていました。

サイト管理者がアップグレードを正常に完了できるよう、インスタンスによってプレフライト チェックが実行されて、仮想マシンが最小ハードウェア要件を満たしていることが確認されます。 このチェックでは、Elasticsearch の正常性も検証されます。 GitHub Enterprise Server の CPU、メモリ、ストレージの現在の要件は、「GitHub Enterprise Server インスタンスをセットアップする」の各記事の「最小要件」セクションで確認できます。

移行用のリポジトリ アーカイブに is_archived フィールドが含まれるようになりました。

高: GitHub アプリは、スコープを指定されたユーザーからサーバーへのトークンを使って、ユーザー認可ロジックをバイパスし、特権をエスカレートできました。

中: GitHub アプリのアクセス可能なファイルの一覧で、Unicode の右から左への上書き文字を使うと、アプリがアクセスできる追加のファイルが隠される可能性がありました。

低: ブランチ保護をバイパスする機能をユーザーに許可しても、署名検証の要件のバイパスがユーザーに許可されることはなくなりました。

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

証明書のサブジェクト文字列に UTF-8 文字が含まれている場合、TLS 証明書のインストールが失敗しました。

管理者が ghe-config を使って retry-limit または retry-sleep-duration を手動で設定した場合、構成の実行が失敗する可能性がありました。

ghe-find-insecure-git-operations コマンドが、各呼び出しの後で、安全ではないすべての Git 操作を返しませんでした。

場合によっては、管理コンソールのモニター ダッシュボードが正しく読み込まれませんでした。

管理コンソール モニター グラフを PNG イメージとしてエクスポートするための機能しないリンクを削除しました。

ghe-support-upload を使ってサポート バンドルを GitHub Enterprise Support に送信するとき、-t オプションを指定しても、アップロードされるバンドルが指定したチケットと正常に関連付けられませんでした。

まれに、GitHub Enterprise Server 3.3 から 3.4 にアップグレードすると、データの格納方法が誤って変更され、その後のアップグレードの間にエラーが発生しました。 3.3 からこのリリースに直接アップグレードすると、エラーは発生しません。

GitHub パッケージの AWS S3 URL として VPC エンドポイントの URL を使うと、パッケージの発行とインストールが失敗しました。

SSH 経由で Git をクローンまたはフェッチすると、サイズが 1 GB を超える転送でデータが破損する可能性がありました。

インスタンスの Enterprise アカウントのセキュリティ設定に戻るリンクで、正しくないビューが表示される可能性がありました。

ユーザーが Web インターフェイスからパッケージを削除または復元した後、パッケージの数が正しくレンダリングされない場合がありました。

Dependabot とアラート ダイジェスト メールを正しく構成した後、インスタンスでダイジェスト メールが送信されませんでした。

GitHub Enterprise Server 3.5 にアップグレードした後、リリースがリポジトリからなくなっているように見えました。 これは、必要な Elasticsearch インデックスの移行が正常に完了していない場合に発生しました。 リリース UI で、Elasticsearch インデックスの移行が完了するのを待っているかどうかと、状態を確認してすぐに移行を完了する方法に関するドキュメントへのリンクが示されるようになりました。

2048 個より多くのコミットを含むプッシュをリポジトリが受け取った場合、またはリポジトリの既定のブランチが変更された場合、リポジトリ内の手動で無効にした GitHub Actions ワークフローが再び有効にされていました。

変更の間に多数の行がある大きなファイルに対する pull request の差分を表示すると、すべての変更が表示されるようにビューを展開できませんでした。

ブランチの保護を有効にした場合、GitHub Actions ワークフローの実行の GITHUB_REF_PROTECTED 環境変数と github.ref_protected コンテキストが、false と正しく設定されませんでした。

GitHub Advanced Security を使っているインスタンスで、シークレット スキャンによって、パブリック リポジトリに追加された個人用アクセス トークンが自動的に取り消されました。

パッケージのリポジトリに、[使用元] セクションが誤って表示されました。

一時的なアクセスのためにリポジトリのロックを解除した後、サイト管理者はリポジトリのセキュリティ製品の設定を管理できませんでした。

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

http(s)://HOSTNAME/stafftools/users/USERNAME/admin の個々のユーザーのサイト管理ページに、GitHub Enterprise Server を対象としていない機能が含まれていました。

ghe-cluster-config-apply を実行すると、空の構成をクラスターの既存のノードにレプリケートされることがありました。

ghe-config-apply で開始された構成の実行が完了しなかったり、Container count mismatch エラーが返されることがありました。

GitHub Enterprise Server インスタンス上の自己署名 TLS 証明書を更新した後、Web インターフェイスの一部のページの UI 要素が表示されませんでした。

Web インターフェイスの上部のサイト管理者バーに含まれる、現在実行中のアプリケーションのバージョンに対する SHA へのリンクが、壊れていました。

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

サイト管理者が GitHub Enterprise Server 3.4 に直接アップグレードしなかった場合、GitHub Advanced Security のお客様に対するシークレット スキャンからのアラートが、Web UI と REST API に表示されませんでした。 現在は、アラートが表示されます。

ユーザーがリポジトリを Organization にフォークするとき、Organization の長い一覧が正しくレンダリングされませんでした。

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

organization または org ルートを含む API が、Organization のスラッグまたは ID を受け取るようになりました。 以前の API はスラッグのみを受け取っており、そのために GitHub Advanced Security エンドポイントの Link ヘッダーにアクセスできませんでした。 詳細については、REST API のドキュメントの「Organization」を参照してください。

Enterprise の監査ログに含まれるユーザー生成イベントが増えました (project.create など)。 REST API からも、追加のユーザー生成イベントが返されます (repo.create など)。 詳細については、「企業の監査ログにアクセスする」および「エンタープライズの監査ログ API を使う」を参照してください。

キャッシュ レプリカが、最近更新されたリポジトリでの一部の Git 操作を拒否することがありました。 リポジトリ キャッシュについて詳しくは、「リポジトリのキャッシュについて」をご覧ください。

重大: GitHub Enterprise Server の Elasticsearch コンテナーで使われていたバージョンの OpenJDK 8 は、悪意のある XSLT スタイルシートを処理するときの整数切り捨ての問題に脆弱でした。 この脆弱性は CVE-2022-34169 として追跡されます。

高: ユーザー アカウントが Organization アカウントに変換された後、ユーザー アカウントに前にインストールされていたアプリに、スコープ付きのアクセス トークンで Organization にアクセスするためのアクセス許可が自動的に付与されました。 この脆弱性は、GitHub Bug Bounty プログラムを通じて報告されました。

r4.4xlarge インスタンスの種類を使用する AWS 上の GitHub Enterprise Server インスタンスが、起動に失敗することがありました。

pull request の [変更されたファイル] タブ内の UI 要素が重なることがありました。

カスタム休眠しきい値がインスタンスに設定されている場合、すべての休眠ユーザーの一時停止で、しきい値が確実に適用されませんでした。 休眠について詳しくは、「休眠ユーザの管理」をご覧ください。

GitHub Advanced Security のコミッター数を計算するとき、個別のリポジトリを指定できませんでした。 詳しくは、「サイトアドミンのダッシュボード」を参照してください。

Elasticsearch のアップグレード後の es:upgrade プロセスが、完了する前にクラッシュすることがありました。

内部リポジトリに移行するためのスクリプトが、パブリック リポジトリの可視性を内部またはプライベートに変換できませんでした。 移行について詳しくは、「インターナルリポジトリへの移行」をご覧ください。

依存関係グラフのための GitHub Actions ワークフロー ファイルの検出は、GitHub Enterprise Server 3.5.0、3.5.1、3.5.2、3.5.3 では利用できなくなりましたが、3.5.4 で利用できるようになりました。 詳しくは、「依存関係グラフについて」を参照してください。

閉じられた Dependabot アラートをもう一度開く機能は、GitHub Enterprise Server 3.5.0、3.5.1、3.5.2、3.5.3 では利用できなくなりましたが、3.5.4 で利用できるようになりました。 詳しくは、「Dependabot アラートの表示と更新」を参照してください。

ベース ブランチから pull request の HEAD への更新を常に提案する機能は、GitHub Enterprise Server 3.5.0、3.5.1、3.5.2、3.5.3 では利用できなくなりましたが、3.5.4 で利用できるようになりました。 詳しくは、「プルリクエスト ブランチを更新する提案の管理」を参照してください。

明るいハイ コントラスト テーマは、GitHub Enterprise Server 3.5.0、3.5.1、3.5.2、3.5.3 では利用できなくなりましたが、3.5.4 で利用できるようになりました。 詳しくは、「テーマ設定を管理する」を参照してください。

pre_receive_hook.rejected_push イベントが Enterprise の監査ログに表示されませんでした。

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

中: 攻撃者が GitHub Enterprise Server Web インターフェイス内のドロップダウン UI 要素でクロスサイト スクリプト (XSS) の脆弱性を悪用することにより、JavaScript のコードを実行するのを防ぎます。

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

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

中: GitHub Enterprise Server で、任意の属性のインジェクションを可能にする格納された XSS の脆弱性が見つかりました。 このインジェクションは、Github の Content Security Policy (CSP) によってブロックされました。 この脆弱性は、GitHub バグ報奨金プログラムを通じて報告され、CVE-2022-23733 が割り当てられました。 [更新日: 2022 年 7 月 31 日]

中: 信頼されていないデータの逆シリアル化に関連する脆弱性が GitHub Enterprise Server で特定され、Subversion (SVN) ブリッジでリモート コードが実行される可能性があります。 この脆弱性を悪用するには、攻撃者が逆シリアル化されるデータを攻撃者が制御できるように、サーバー側リクエスト フォージェリ (SSRF) を介してアクセスする必要があります。 この脆弱性は、GitHub バグ報奨金プログラムを通じて報告され、CVE-2022-23734 が割り当てられました。

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

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

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

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

GitHub Enterprise Importer は、リポジトリ内のプロジェクトに対する設定を正しく移行しませんでした。

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

サイト管理者ダッシュボードに、休眠ユーザーの一覧レポートをエクスポートするオプションが誤って含まれていました。

課金 API の「課金」エンドポイントが Link ヘッダーを返すことで、改ページに関する情報を提供します。

課金 API の「課金」エンドポイントがコミッター総数の正しい数値を返します。

組織の設定のサイドバーで、 [Archive] (アーカイブ) ナビゲーション項目に子要素がありませんでした。

VMware vSphere ESXi ハイパーバイザー バージョン 7.0 がサポートされるようになりました。 [更新日: 2022 年 9 月 7 日]

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

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

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

中: GitHub Enterprise Server の URL に org クエリ文字列パラメーターを指定して、別の組織のアクティブなコミッターにアクセスできるようにする攻撃を防ぎます。

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

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

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

アクセス許可に制限があるため、成果物アーカイブ内のファイルを展開後に開くことができませんでした。

場合によっては、コンテナー レジストリにプッシュされたパッケージが GitHub Enterprise Server の Web UI に表示されませんでした。

プロビジョニング不足のインスタンスを GitHub Enterprise Server 3.5 にアップグレードした後、管理コンソールの表示が "開始" 画面でスタックしました。__

ghe-config-apply の実行中に、Redis のタイムアウトでデータベースの移行が停止しなくなりました。

バックグラウンド ジョブ プロセッサが部分的なシャットダウン状態でスタックし、結果として特定の種類のバックグラウンド ジョブ (Code Scanning など) がスタックしているように見えていました。

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

他の再利用可能なワークフローを呼び出すアクション ワークフローを、スケジュールに従って実行できませんでした。

リポジトリの可視性をパブリックから内部に変更した後、GitHub Connect を使う Actions の解決が短時間失敗しました。

Dependabot の更新を初めて有効にしたときのパフォーマンスが向上しました。

GHES パフォーマンス ターゲットをサポートするため、Actions ランナーの最大コンカレント接続数を増やします。

GitHub Pages のビルドと同期のタイムアウトは、管理コンソールで構成できるようになりました。

Redis のタイムアウトを構成するための環境変数を追加しました。

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

diff に多くの変更が含まれている場合に、pull request の [変更されたファイル] タブのパフォーマンスが向上します。

Actions リポジトリ キャッシュの使用ポリシーで、max_repo_cache_size_limit_in_gb に対して 1 未満の最大値が受け付けられなくなりました。

cache-server ノードのデプロイ時に、システム内のすべてのノードに対してデータセンター トポロジの記述 (--datacenter 引数の使用) が必須になりました。 データセンターのメンバーシップを "既定値" に設定したままにしておくと、複数のデータセンター間でワークロードが不適切に分散されるという状況は、この要件によって回避されます。

VMware vSphere ESXi ハイパーバイザー バージョン 7.0 がサポートされるようになりました。 [更新日: 2022 年 9 月 7 日]

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

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

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

GitHub Enterprise Server 3.4.1 以降で GitHub Actions が有効であり、TLS が無効な場合、構成の更新の適用に失敗しました。

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

GitHub Advanced Security 課金 API エンドポイントが有効ではなく、アクセスできませんでした。

削除された画像添付ファイルは、404 Not Found エラーの代わりに 500 Internal Server Error を返します。

リポジトリ キャッシュ サーバーで構成された環境で ghe-repl-status コマンドを実行すると、gist がレプリケート不足であると誤って表示されました。

Commit API の "Get a commit" (コミットの取得) と "Compare two commits" (2 つのコミットの比較) エンドポイントを使い、エンコードされ、エスケープされた unicode 文字が差分のファイル パスに含まれている場合、500 エラーが返されました。

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

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

GitHub App が、インストールで secret_scanning_alert_location Webhook イベントをサブスクライブできないことがありました。

Secret Scanning アラートのアクティビティ タイムラインが表示されませんでした。

削除されたリポジトリは 90 日後に消去されませんでした。

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

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

VMware vSphere ESXi ハイパーバイザー バージョン 7.0 がサポートされるようになりました。 [更新日: 2022 年 9 月 7 日]

メンテナンス モードが有効になっている間に GitHub Enterprise Server インスタンス上のアプリケーション サービスにアクセスできる IP アドレスの許可リストを構成できるようになりました。 許可された IP アドレスからインスタンスの Web インターフェイスにアクセスする管理者は、メンテナンスの後、メンテナンス モードを無効にする前に、インスタンスの機能を検証できます。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。

Organization は、カスタム リポジトリ ロールを使うことで、ユーザーに付与できるリポジトリのアクセス許可を、より細かく制御できます。 詳細については、「Organization のカスタム リポジトリ ロールの管理」を参照してください。

カスタム リポジトリ ロールは、Organization の所有者によって作成され、その Organization 内のすべてのリポジトリで使用できます。 ロールごとに、カスタム名と説明を指定できます。 40 より多くのきめ細かいアクセス許可のセットから構成できます。 作成した後、リポジトリ管理者は、リポジトリ内のユーザー、チーム、または外部コラボレーターに、カスタム ロールを割り当てることができます。

カスタム リポジトリ ロールは、組織の設定の新しい [Repository roles] (リポジトリ ロール) タブで作成、表示、編集、削除することができます。 1 つの Organization 内に、最大 3 個のカスタム ロールを作成できます。

カスタム リポジトリ ロールは、GitHub Enterprise Server REST API でも完全にサポートされます。 Organizations API を使うと、Organization 内のすべてのカスタム リポジトリ ロールの一覧を表示できます。また、個人やチームにリポジトリへのアクセスを許可する既存の API は、カスタム リポジトリ ロールをサポートするように拡張されています。 詳細については、REST API のドキュメントの「Organization (組織)」を参照してください。

GitHub Enterprise Server 3.5 でパブリック ベータとして利用できるようになった GitHub Container Registry (GHCR) は、コンテナーを発行、ダウンロード、管理する機能を開発者に提供します。 GitHub Packages のコンテナー サポートでは、Docker イメージをホストするための OCI 標準が実装されます。 詳細については、GitHub コンテナー レジストリに関するページを参照してください。

Dependabot のバージョンとセキュリティの更新が、GitHub Enterprise Server 3.5 で一般提供されるようになりました。 GitHub.com リポジトリで動作する人気のあるすべてのエコシステムと機能を、GitHub Enterprise Server インスタンスでセットアップできるようになりました。 GitHub Enterprise Server 上の Dependabot には、GitHub Actions およびセルフホステッド Dependabot ランナーのプールが必要で、GitHub Connect と Dependabot を管理者が有効にする必要があります。詳細については、Dependabot 更新の設定に関するページを参照してください。

インスタンスの使用状況データをレビューし、集計データを GitHub と共有することで、チームの作業状況を分析し、GitHub Enterprise Server から取得した値を理解し、製品の向上に役立てることができるようになりました。 データを CSV または JSON ファイルでダウンロードするか、REST API を使ってデータにアクセスすることで、独自のツールを使って使用状況を経時的に分析できます。 収集される集計メトリックの一覧については、「Server Statistics について」を参照してください。 Server Statistics のデータには、個人データも、コード、issue、コメント、pull request の内容などの GitHub のコンテンツも含まれません。 Server Statistics のデータが格納およびセキュリティ保護される方法の詳細については、GitHub のセキュリティに関する記事を参照してください。 Server Statistics の詳細については、「チームがサーバー統計と連携する方法の分析」を参照してください。 この機能はパブリック ベータで使用できます。

サイト管理者は、GitHub Actions のレート制限を有効にして構成できるようになりました。 既定では、レート制限は無効です。 使用可能なランナーにワークフロー ジョブをすぐに割り当てることができない場合、ジョブはランナーが使用可能になるまでキューで待機します。 ただし、GitHub Actions の負荷が常に高い場合、キューからの流出よりキューへの流入の方が速くなり、GitHub Enterprise Server インスタンスのパフォーマンスが低下する可能性があります。 これを避けるため、管理者はレート制限を構成することができます。 レート制限を超えると、それ以上のワークフロー実行は、キューに入れられるのではなく、すぐに失敗します。 レートがしきい値より低下して安定したら、新しい実行を再びキューに入れられるようになります。 詳細については、「レート制限の設定」を参照してください。

GitHub Enterprise Server 上の GitHub Actions で、クラウド プロバイダーへの安全なデプロイのために OIDC がサポートされるようになりました。この機能では、デプロイのたびに自動的にローテーションされる、有効期間の短いトークンが使われます。 OIDC により次の機能が有効になります。

• クラウド プロバイダーと GitHub Enterprise Server の間のシームレスな認証。有効期間の長いクラウド シークレットをインスタンスに格納する必要はありません
• クラウド管理者は、特定のクラウド プロバイダーのセキュリティ メカニズムに依存して、GitHub Actions のワークフローによるクラウド リソースへのアクセスを最小限にできます。 GitHub Enterprise Server とクラウドの間にシークレット管理の重複はありません。

詳細については、「デプロイのセキュリティ強化」を参照してください。

内部リポジトリでの GitHub Actions のサポートが、GitHub Enterprise Server インスタンス上の Organization で一般提供されるようになりました。 内部リポジトリでアクションを共有することにより、オートメーションを内部ソーシングできます。 リポジトリの設定を管理したり、REST API を使って、Organization 内またはインスタンス上の任意の Organization の他のリポジトリのワークフローへのアクセスを許可したりできます。 詳細については、REST API ドキュメントの「エンタープライズとのアクションとワークフローの共有」、「リポジトリの GitHub Actions 設定の管理」、「Actions のアクセス許可」を参照してください。

依存関係キャッシュを使って、GitHub Actions のワークフローを高速化できるようになりました。 ジョブの依存関係をキャッシュするには、actions/cache アクションを組み込み、一意のキーを使ってキャッシュを作成できます。 同じリポジトリ内のすべてのワークフローの間で、キャッシュを共有できます。 その後、これらのワークフローでキャッシュを復元し、実行速度を上げることができます。

Actions のユーザーは、キャッシュ API を使って次のこともできます。

• リポジトリごとに許容されるキャッシュ サイズの範囲に関するエンタープライズ ポリシーを定義します。
• 各リポジトリ内のキャッシュの使用に関するクエリを実行し、すべてのキャッシュの合計サイズが上限に達しているかどうかを監視します。
• リポジトリのキャッシュ要件に基づいて、エンタープライズで許容される制限内でリポジトリの最大キャッシュ サイズを増やします。
• 組織レベルまたはエンタープライズ レベルで集計されたキャッシュの使用状況を監視します。

Enterprise アカウント内で構成されている外部 BLOB ストレージを、ワークフローの成果物、ログ、キャッシュの間で共有できるようになります。 詳細については、「依存関係をキャッシュしてワークフローのスピードを上げる」を参照してください。

Web インターフェイスのファイルの編集や pull request のマージなどから行われたコミットに自動的に署名するように、GitHub Enterprise Server を構成できるようになりました。 コミットが署名されていると、変更が信頼できるソースからのものであることを、いっそう強く確信できます。 この機能を使うと、署名済みコミットの必須化のブランチ保護設定により、署名されていないコミットがリポジトリに入るのを防ぎながら、署名されたコミットが (Web インターフェイスで行われたものであっても) 入るのを許可できます。 詳細については、「Web コミット署名を構成する」を参照してください。

ライセンスの利用状況を GitHub Enterprise Server と GitHub Enterprise Cloud の間で GitHub Connect を使って自動的に同期しているお客様は、毎週の自動同期とは関係なく、ライセンスの利用状況を同期できるようになりました。この機能により、同期ジョブの状態も報告されます。 詳細については、「GitHub Enterprise Server と GitHub Enterprise Cloud 間のライセンス使用状況の同期」を参照してください。

再利用可能なワークフローが一般提供されるようになりました。 再利用可能なワークフローは、ワークフロー全体を 1 つのアクションであるかのように再利用できるので、重複を減らすのに役立ちます。 一般提供リリースには、GitHub Enterprise Server で利用できるようになった機能強化がいくつかあります。 詳細については、「ワークフローの再利用」を参照してください。

• 出力を利用して、再利用可能なワークフローから呼び出し元ワークフローの他のジョブに、データを渡すことができます。
• 環境のシークレットを再利用可能なワークフローに渡すことができます。
• 監査ログには、使われた再利用可能なワークフローに関する情報が含まれます。
• 呼び出し元リポジトリと同じリポジトリ内の再利用可能なワークフローは、パスとファイル名 (PATH/FILENAME) だけで参照できます。 呼び出されるワークフローは、呼び出し元ワークフローと同じコミットのものです。

セルフホステッド ランナーがソフトウェア更新を実行するタイミングを、いっそうきめ細かに制御できるようになりました。 ランナーに --disableupdate フラグを指定すると、より新しいバージョンのランナーを利用できる場合は、自動ソフトウェア更新の実行が試みられません。 これにより、セルフホステッド ランナーを独自のスケジュールで更新でき、セルフホステッド ランナーがコンテナー内にある場合に特に便利です。

GitHub Actions サービスとの互換性のため、ランナーの新しいバージョンが利用できるようになってから 30 日以内に、ランナーを手動で更新する必要があります。 ランナーの最新バージョンをインストールする方法については、ランナー リポジトリにある最新リリースのインストール手順をご覧ください。

Organization の所有者は、ランナー グループにアクセスできるワークフローを選ぶことで、セルフホステッド ランナー上の CI/CD ワークフローのセキュリティを強化できるようになりました。 これまでは、issue ラベラーなど、リポジトリ内の任意のワークフローが、Organization で利用できるセルフホステッド ランナーにアクセスできました。 詳細については、「グループを使用してセルフホステッド ランナーへのアクセスを管理する」と GitHub ブログを参照してください。

GitHub Actions で pull request を承認できるかどうかを制御できるようになりました。 この機能は、GitHub Actions を使うユーザーが、"必要な承認" ブランチ保護要件を満たして、別のユーザーによってレビューされていない変更をマージするのを防ぎます。 既存のワークフローが壊れないように、 [Allow GitHub Actions reviews to count towards required approval] (GitHub Actions のレビューを必要な承認にカウントできるようにする) は既定で有効になります。 Organization の所有者は、Organization の GitHub Actions の設定で、この機能を無効にできます。 詳細については、「組織の GitHub Actions の無効化または制限」を参照してください。

GitHub Actions ワークフローの実行の失敗したジョブまたは個別のジョブだけを、再実行できるようになりました。 詳しくは、「ワークフローとジョブの再実行」をご覧ください。

依存関係グラフで、GitHub Actions ワークフロー用の YAML ファイルが検出されるようになりました。 GitHub Enterprise Server の [Insights] (分析情報) タブの依存関係グラフ セクション内に、ワークフローのファイルが表示されます。 アクションを発行するリポジトリのホーム ページの "[使用元]" コントロールでは、そのアクションに依存するリポジトリの数を見ることもできます。 詳細については、「依存関係グラフの概要」を参照してください。

• 注: この機能は、GitHub Enterprise Server 3.5.0、3.5.1、3.5.2、3.5.3 では使用できませんでした。 この機能は 3.5.4 以降で使用できます。 [更新日: 2022-08-16]

GitHub Advanced Security のお客様は、Enterprise レベルでセキュリティ アラートの概要を見ることができるようになりました。 エンタープライズ レベルの新しい [Security] (セキュリティ) タブでは、アプリケーションのセキュリティ リスクのリポジトリ中心のビューと、すべてのシークレット スキャン アラートのアラート中心のビューが提供されます。 詳細については、「セキュリティの概要について」を参照してください。

Organization レベルでのセキュリティ アラートの概要が、一般提供されるようになりました。 GitHub Advanced Security のお客様は、セキュリティの概要を使って、Organization 内のすべてのリポジトリについて、アプリケーションのセキュリティ リスクのリポジトリ中心のビュー、またはすべてのコード スキャン、Dependabot、シークレット スキャンのアラートのアラート中心のビューを、見ることができます。 詳細については、「セキュリティの概要について」を参照してください。

コード スキャンでいっそう多くの CWE が検出されるようになり、CodeQL のコード スキャンで次の言語リリースの標準言語機能がサポートされるようになりました。

• C# 10、.NET 6
• Python 3.10
• Java 17
• TypeScript 4.5

詳細については、GitHub ブログを参照してください。

GitHub Advanced Security のお客様は、組織の [Security] (セキュリティ) タブでコード スキャンのアラートを見ることができるようになりました。このビューを利用できるのは、組織の所有者と、セキュリティ マネージャー ロールを持つチームのメンバーです。 詳細については、「セキュリティの概要について」を参照してください。

ユーザーは、GitHub Enterprise Server インスタンス上の Organization に対するコード スキャンのアラートを、REST API で取得できるようになりました。 この新しい API エンドポイントは、既存のリポジトリに対するエンドポイントを補完します。 詳細については、REST API ドキュメントの「コード スキャン」を参照してください。

GitHub Enterprise Server は、高い確度でトークンが検出されるプッシュをブロックできるようになりました。 開発者は、Web UI を通してシークレットをコミットする必要がある詳細な理由を提供することで、ブロックをバイパスできます。 詳細については、「Protecting pushes with secret scanning (シークレット スキャンによるプッシュの保護)」を参照してください。

GitHub Advanced Security のお客様は、Organization またはリポジトリのレベルでカスタム シークレット スキャン パターンのドライ ランを実行できるようになりました。 所有者または管理者のアクセス権を持つユーザーは、パターンを発行してアラートを生成する前に、ドライ ランを行うことで、パターンを確認して調整できます。 パターンを作成した後、 [Save and dry run] (保存してドライ ラン) を使って結果を取得できます。 通常、スキャンにかかる時間はほんの数秒ですが、ドライ ランの結果の準備ができると、GitHub Enterprise Server から Organization 所有者またはリポジトリ管理者にメールでも通知されます。 詳細については、「シークレット スキャンについて」と「シークレット スキャンのカスタム パターンの定義」を参照してください。

監査ログに、シークレット スキャンのカスタム パターンに関連付けられたイベントが含まれるようになりました。 このデータは、GitHub Advanced Security のお客様が、セキュリティとコンプライアンスの監査のためにリポジトリ、組織、またはエンタープライズ レベルのカスタム パターンで実行されるアクションを理解するのに役立ちます。 詳細については、「組織の監査ログをレビューする」と「エンタープライズの監査ログをレビューする」を参照してください。

カスタム リポジトリ ロールを管理するとき、シークレット スキャンのために 2 つの新しいアクセス許可を構成できるようになりました。

• シークレット スキャンの結果を表示する
• シークレット スキャンの結果を閉じるか、もう一度開く

詳細については、「組織のカスタム リポジトリ ロールの管理」を参照してください。

GitHub Advanced Security のお客様は、UI と API から、アーカイブされたリポジトリのシークレット スキャンを有効にできるようになりました。 詳細については、REST API ドキュメントの「シークレット スキャンについて」、「アーカイブされたリポジトリについて」、「リポジトリ」を参照してください。

シークレット スキャンを使っている GitHub Advanced Security のお客様は、新しい場所でシークレットが検出されるたびに Webhook を受け取れるようになりました。 secret_scanning_alert_location Webhook イベントには、コミット SHA のような場所の詳細と、検出の関連アラートが含まれます。 検出されたシークレットを含むすべての新しいファイル パスに対して場所が作成されます。 詳細については、「webhook イベントとペイロード」を参照してください。

GitHub Advanced Security のお客様は、組織の [Security] (セキュリティ) タブで Dependabot のアラートを見ることができるようになりました。このビューを利用できるのは、組織の所有者と、セキュリティ マネージャー ロールを持つチームのメンバーです。 詳細については、「セキュリティの概要について」を参照してください。

カスタム リポジトリ ロールを管理するとき、Dependabot アラートのために 2 つの新しいアクセス許可を構成できるようになりました。

• Dependabot アラートを表示する
• Dependabot アラートを閉じるか、もう一度開く

詳細については、「組織のカスタム リポジトリ ロールの管理」を参照してください。

閉じられたアラートの UI ページを使って、閉じられた Dependabot アラートをもう一度開くことができるようになりました。 これにより、Dependabot の pull request または GraphQL API への影響はありません。 詳細については、「Dependabot アラートについて」を参照してください。

• 注: この機能は、GitHub Enterprise Server 3.5.0、3.5.1、3.5.2、3.5.3 では使用できませんでした。 この機能は 3.5.4 以降で使用できます。 [更新日: 2022-08-16]

Dependabot バージョン更新のユーザーは、Pub パッケージ マネージャーを使う Flutter または Dart プロジェクトの依存関係を、プロアクティブに更新できるようになりました。

ご自身の Dart または Flutter リポジトリでバージョンの更新をテストするには、.github/dependabot.yaml に次の構成ファイルを追加します。 package-ecosystem: "pub" と enable-beta-ecosystems: true のフラグに注意してください。

version: 2
enable-beta-ecosystems: true
updates:
  - package-ecosystem: "pub"
    directory: "/"
    schedule:
      interval: "weekly"

新しい DependabotUpdate GraphQL オブジェクトを使うと、リポジトリのセキュリティ更新に対して行われることに関する情報を表示できます。 リポジトリ内の依存関係が脆弱であることを GitHub Enterprise Server が検出すると、Dependabot は pull request を開いて、その依存関係を脆弱ではないバージョンに更新しようとします。 脆弱性を修正する pull request を見ることができるようになりました。 Dependabot が pull request を開けないことがあります。 これまでは、Dependabot によって生成されたエラー メッセージは、 [Security] (セキュリティ) タブの [Dependabot Alerts] (Dependabot アラート) セクションでのみ見ることができました。今は、セキュリティ アラートに関する pull request を開こうとして Dependabot がエラーになった場合、GraphQL API を使ってその理由を特定できます。 詳細については、GraphQL API ドキュメントの「オブジェクト」を参照してください。

GraphQL API を使って、Dependabot の修正済みアラートを表示できるようになります。 また、アクセスして状態や一意の数値識別子でフィルター処理したり、脆弱性アラート オブジェクトの状態でフィルター処理したりすることもできます。 RepositoryVulnerabilityAlert に次のフィールドが存在するようになりました。

• number
• fixed_at
• fix_reason
• state

詳細については、GraphQL API ドキュメントの「オブジェクト」を参照してください。

次の Git 関連イベントを、Enterprise 監査ログに記録できるようになりました。 この機能を有効にして、監査ログの保持期間を設定した場合、新しいイベントを、UI や API を使って検索したり、JSON または CSV でエクスポートしたりできるようになります。

• git.clone
• git.fetch
• git.push

ログされる Git イベントの数が多いため、インスタンスのファイル ストレージを監視し、関連するアラート構成を確認することをお勧めします。 詳しくは、「企業の監査ログの構成」を参照してください。

このリリースには、CODEOWNERS の機能強化が含まれます。

• Web から CODEOWNERS ファイルを表示すると、構文エラーが示されるようになりました。 これまでは、CODEOWNERS ファイルの行に構文エラーがあると、エラーが無視されたり、場合によっては CODEOWNERS ファイル全体が読み込まれなかったりしました。 新しい REST と GraphQL API を使うと、GitHub Apps と Actions で同じエラー リストにアクセスできます。 詳細については、REST API ドキュメントの「リポジトリ」または GraphQL API ドキュメントの「オブジェクト」を参照してください。
• 誰かが新しい pull request を作成したり、ドラフトの pull request に新しい変更をプッシュしたりした後、レビューを要求されるコード所有者が、pull request の [Reviewers] (レビュー担当者) の一覧に表示されるようになります。 この機能を使うと、pull request がレビューできる状態になった後で、そのレビューを要求されるユーザーを早期に確認できます。
• CODEOWNERS ファイルのコメントを、それ専用の行だけでなく、行の末尾に表示できるようになります。

詳細については、「コードオーナーについて」を参照してください。

pull request ページの [Update branch] (ブランチの更新) ボタンを使うと、pull request のブランチを、ベース ブランチからの最新の変更で更新できます。 これは、マージする前に、変更がベース ブランチの現在のバージョンと互換性があることを確認するのに便利です。 2 つの機能強化により、さらに多くの方法で、ブランチを最新の状態に維持できます。

• pull request のトピック ブランチがベース ブランチより古くなったら、ベース ブランチの最新バージョンにリベースすることによって更新できるようになりました。 リベースでは、自分のブランチの変更がベース ブランチの最新バージョンに適用され、マージ コミットが作成されないので、結果は線形履歴を持つブランチになります。 リベースで更新するには、 [Update branch] (ブランチの更新) ボタンの隣にあるドロップダウン メニューをクリックし、 [Update with rebase] (リベースで更新) をクリックしてから、 [Rebase branch] (ブランチのリベース) をクリックします。 これまでの [Update branch] (ブランチの更新) では、常に pull request ブランチのマージ コミットになる従来のマージが実行されました。 このオプションはまだ使用できますが、選択するようになりました。 詳細については、「Keeping your pull request in sync with the base branch (プルリクエスト を基本ブランチと同期された状態に維持する)」を参照してください。

• リポジトリの新しい設定では、pull request のトピック ブランチがベース ブランチに対して最新でないときは常に、 [Update branch] (ブランチの更新) ボタンを使用できます。 これまで、このボタンは、 [Require branches to be up to date before merging] (マージする前にブランチを最新にする必要がある) のブランチ保護設定が有効になっているときにのみ使用できました。 管理者または保守管理者のアクセス権を持つユーザーは、リポジトリの設定の [Pull Request] セクションから [Always suggest updating pull request branches] (pull request ブランチの更新を常に推奨する) の設定を管理できます。 詳細については、「pull request ブランチを更新する提案の管理」を参照してください。

  • 注: この機能は、GitHub Enterprise Server 3.5.0、3.5.1、3.5.2、3.5.3 では使用できませんでした。 この機能は 3.5.4 以降で使用できます。 [更新日: 2022-08-16]

GitHub Enterprise Server インスタンスから提供されるすべての GitHub Pages サイトに適用されるカスタム HTTP ヘッダーを構成できるようになりました。 詳細については、「エンタープライズ用の GitHub Pages の構成」を参照してください。

リポジトリのルートに .git-blame-ignore-revs ファイルを作成することにより、変更履歴ビューでリビジョンを無視できるようになりました。 詳細については、「ファイルの表示」を参照してください。

前景と背景の要素の間のコントラストがより大きい明るいハイ コントラスト テーマが、一般提供されるようになりました。 詳細については、「テーマ設定を管理する」を参照してください。

• 注: この機能は、GitHub Enterprise Server 3.5.0、3.5.1、3.5.2、3.5.3 では使用できませんでした。 この機能は 3.5.4 以降で使用できます。 [更新日: 2022-08-16]

リポジトリ所有者は、タグ保護ルールを構成してリポジトリのタグを保護できるようになりました。 タグ保護ルールで保護すると、指定した名前パターンに一致するタグは、リポジトリの保守管理者または管理者ロールを持つユーザーだけが、作成および削除できるようになります。 詳細については、「タグ保護ルールの構成」を参照してください。

GitHub Mobile for iOS 1.80.0 以降では、ユーザーは pull request のトピック ブランチ内でファイルを編集できるようになりました。 GitHub Mobile for Android でのファイルの編集のサポートは、今後のリリースで提供される予定です。 [更新日: 2022 年 9 月 13 日]

GitHub Apps でリリース アセットをアップロードできるようになりました。

GitHub Enterprise Server 2.10 と 3.0 で、ルート ストレージとメモリの最小要件が増加し、3.5.0 以降は強制されるようになりました。

• バージョン 2.10 では、ルート ストレージの最小要件が 80 GB から 200 GB に増加しました。 3.5.0 以降は、ルート ストレージが 80 GB 未満の場合、システムのプレフライト チェックに失敗します。
• バージョン 3.0 では、メモリの最小要件が 16 GB から 32 GB に増加しました。 3.5.0 以降は、システムのメモリが 28 GB 未満の場合、システムのプレフライト チェックに失敗します。

詳細については、「GitHub Enterprise Server インスタンスの設定」のサポートされている各デプロイ プラットフォームの最小要件を参照してください。 [更新日: 2022 年 6 月 20 日]

VMware vSphere ESXi ハイパーバイザー バージョン 7.0 がサポートされるようになりました。 [更新日: 2022 年 9 月 7 日]

OAuth と GitHub Apps でデバイス認可フローを使うには、機能を手動で有効にする必要があります。 この変更により、インテグレーターはリスクを認識し、この形式の認証をサポートすることを意識的に選択するようになるため、GitHub Enterprise Server ユーザーに対するフィッシング攻撃にアプリが使われる可能性が減ります。 OAuth App または GitHub App を所有または管理していて、デバイス フローを使いたい場合は、アプリの設定ページでアプリに対してそれを有効にできます。 デバイス フロー API エンドポイントは、この機能が有効になっていないアプリには、状態コード 400 で応答します。 詳細については、「Authorizing OAuth Apps (OAuth アプリの認可)」を参照してください。

コード スキャン アラートのページに、既定のブランチのアラート状態と情報が常に表示されるようになりました。 サイドバーにある新しい Affected branches パネルでは、他のブランチでのアラートの状態を確認できます。 既定のブランチにアラートが存在しない場合、アラート ページの状態では、アラートが最後に検出された場所が In branch または [In pull request](pull request 内) と表示されます。 この改善により、コード ベースに取り込まれたアラートの状態をより簡単に把握できます。 詳細については、「About code scanning alerts」(コード スキャン アラートについて) を参照してください。

アラート リスト ページは変更されておらず、branch でフィルター処理できます。 コード スキャン API を使って、アラートに関するさらに詳細なブランチの情報を取得できます。 詳細については、REST API ドキュメントの「コード スキャン」を参照してください。

コード スキャンでアラートの分析元の詳細が示されるようになりました。 アラートに複数の分析元がある場合は、Affected branches サイドバーとアラート タイムラインに表示されます。 Affected branches サイドバーの分析元アイコンをポイントすると、各分析元でのアラートの状態を確認できます。 アラートの分析元が 1 つだけの場合は、アラート ページに分析元に関する情報は表示されません。 これらの改善により、アラートの把握がいっそう簡単になります。 特に、分析元が複数あるアラートの理解に役立ちます。 これは、モノリポなど、複数の分析構成がある設定の場合に特に便利です。 詳細については、「About code scanning alerts」(コード スキャン アラートについて) を参照してください。

ユーザーまたは Organization によって所有されるリポジトリのリストに追加されたフィルター オプション [テンプレート] を使うと、いっそう簡単にテンプレート リポジトリを検索できます。

GitHub Enterprise Server では、一般的な複数の画像形式 (PNG、JPG、GIF、PSD、SVG など) を表示でき、バージョン間の差異を比較する複数の方法が用意されています。 pull request で追加または変更された画像をレビューするとき、それらの画像のプレビューが既定で表示されるようになりました。 以前は、バイナリ ファイルは表示できないことを示すメッセージが表示され、Display rich diff オプションを切り替える必要がありました。 詳細については、「非コード ファイルでの作業」を参照してください。

新しい gist が、既定のブランチ名 main またはユーザー設定で定義されている代替の既定ブランチ名で作成されるようになりました。 これは、GitHub Enterprise Server での他のリポジトリの作成方法と一致します。 詳細については、「ブランチについて」と「リポジトリの既定のブランチ名を管理する」を参照してください。

gist の初期表示では、最新の 30 個のコメントだけが表示されるようになりました。 [さらに前のコメントを読み込む] をクリックしてさらに表示できます。 これにより、多くのコメントが含まれる gist の表示が速くなります。 詳細については、「gist を使ったコンテンツの編集と共有」を参照してください。

ユーザー、Organization、リポジトリ、チームの設定ページのデザインが変更され、情報の構造と見つけやすさが向上するように、似た設定ページがセクションにまとめられました。 詳細については、GitHub の変更ログを参照してください。

ラベルにフォーカスを設定するか、ラベルをポイントすると、ツールヒントにラベルの説明が表示されるようになりました。

リポジトリの招待の作成と削除が、API または Web インターフェイスのどちらを使って行われる場合でも、GitHub Enterprise Server インスタンスで有効にできるレート制限の対象になりました。 レート制限の詳細については、「レート制限の構成」を参照してください。

MinIO から、2022 年 6 月 1 日以降、MinIO Gateway が削除されることが発表されています。 MinIO Gateway for NAS は引き続きストレージ プロバイダーの 1 つとして Github Actions と Github Packages によってサポートされますが、MinIO からのサポートとバグ修正を受けられるよう、MinIO LTS のサポートに移行することをお勧めします。 レート制限の詳細については、minio/minio リポジトリ内の GCS、Azure、HDFS 用 MinIO Gateway のスケジュールされた削除に関するページを参照してください。

GitHub 認証トークンの形式が変更されるため、6 月 3 日を過ぎると、GitHub Enterprise Server 3.1 以前を実行するインスタンスでは、GitHub Connect が動作しなくなります。 引き続き GitHub Connect を使うには、GitHub Enterprise Server 3.2 以降にアップグレードしてください。 詳細については、GitHub ブログを参照してください。 [更新日: 2022 年 6 月 14 日]

CodeQL ランナーは非推奨になったので、CodeQL CLI をお勧めします。 GitHub Enterprise Server 3.4 以降には、CodeQL ランナーは含まれなくなります。 この非推奨は、サード パーティの CI/CD システムで CodeQL のコード スキャンを使用するユーザーにのみ影響します。 GitHub Actions のユーザーには影響ありません。 お客様には、CodeQL ランナーのフィーチャー コンプリート置換であり、多くの機能が追加されている、CodeQL CLI に移行することを強くお勧めします。 詳細については、「CodeQL ランナーから CodeQL CLI への移行」を参照してください。

GitHub Pages 用のテーマ ピッカーは、Pages の設定から削除されました。 GitHub Pages のテーマの構成の詳細については、「Jekyll を使用して GitHub Pages サイトにテーマを追加する」を参照してください。