Enterprise Server 3.6 release notes

中: 統合インストールに対するアクセス許可がダウングレードまたは削除された後、GitHub アプリの範囲指定されたインストール トークンは承認されたアクセス許可を保持していました。 GitHub は、この脆弱性について CVE ID CVE-2023-23765 を要求し、これは GitHub バグ報奨金プログラムを介して報告されました。

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

クラスター構成のインスタンスでは、MySQL マスター ノードをアップグレードするときに、異常なノードが正しく検出されないことが原因で、アップグレード後の構成の実行に 600 秒長く時間がかかっていました。

状況によっては、複数のノードがあるインスタンスでは、以前に削除されたリポジトリを Git レプリケーションで完全にレプリケートできないため、ghe-repl-status 出力に警告が表示されることがありました。

ユーザーがリンクをクリックしてフィードバックを共有したり、ユーザー リストのベータ版のバグを報告したりすると、Web インターフェイスが 404 エラーで応答しました。

インスタンスに数万個の削除されたリポジトリがあった場合、GitHub Enterprise Server 3.7 へのアップグレードに予想以上に時間がかかることがありました。

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

インスタンスへの管理 SSH アクセスを持つユーザーは、ghe-config redis.max-memory-gb VALUE を使用してギガバイト単位で最大メモリ使用量を構成できます。

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

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

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

高可用性構成のインスタンスでは、GitHub Enterprise Server でレプリカ ノードにリポジトリが同時に作成されていた場合、git push 操作が失敗する可能性があります。

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

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

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

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

状況によっては、複数のノードがあるインスタンスでは、以前に削除されたリポジトリを Git レプリケーションで完全にレプリケートできないため、ghe-repl-status 出力に警告が表示されることがありました。

statsd によって解析できない削除された launch.* メトリックにより、結果の statsd エラーによって collectd ログのサイズが急速に増加しました。

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 が有効です。

最終的なダウンロード サイズが報告されるまで Git LFS オブジェクトのダウンロード要求が完了しませんでした。これが、これらの要求 (特にリポジトリ キャッシュとして機能するノードを持つインスタンスに対するもの) の待機時間に影響していました。

場合によっては、管理コンソールのモニター ダッシュボードのグラフをレンダリングできませんでした。

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

削除した組織を復元した後、インスタンスの組織一覧にその組織が表示されませんでした。

クラスターでの構成実行中のエラーを回避するために、cluster.conf ユーティリティを使用した ghe-cluster-config-check の検証により、各ノードの consul-datacenter フィールドがトップレベルの primary-datacenter フィールドと一致することが保証されます。

サイト管理者がインスタンスの GitHub Actions または GitHub Packages の BLOB ストレージに無効な構成を指定した場合、プリフライト チェック ページに詳細とトラブルシューティング情報が表示されます。

高: 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 エラーで失敗しました。

場合によっては、GitHub Advanced Security ライセンスとシークレット スキャンが有効になっているインスタンスで、リポジトリの [セキュリティ] タブと [セキュリティ] タブのサイドバーに表示されるアラートの数が一致しないことがあります。

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

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

/repositories REST API エンドポイントからの応答に、削除されたリポジトリが誤って含まれていました。

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

リポジトリにチェック注釈がある CODEOWNERS ファイルが含まれている場合、pull request の [変更されたファイル] タブで 500 エラーが返され、[チェック注釈がある変更されていないファイル] セクションに "問題が発生しました" と表示されました。

GitHub Advanced Security ライセンスを持つインスタンスを GitHub Enterprise Server 3.6 または 3.7 にアップグレードした後では、リポジトリを作成したとき、または Organization もしくはリポジトリのセキュリティ設定ページを表示したとき、アップグレードの開始前に GitHub Advanced Security のバックフィル ジョブが完了していなかったために 500 エラーが発生することがありました。

GitHub Actions が有効になっているインスタンスで、ユーザーが REST API を使用してワークフローを手動でトリガーしたものの、省略可能なブール値の値を指定しなかった場合、API で要求を検証できず、422 エラーが返されました。

サイト管理者ダッシュボードから利用できる、すべてのユーザーとすべてのアクティブ ユーザーの 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 が含まれていました。

GitHub Advanced Security ライセンスを持つインスタンスで、GitHub Enterprise Server 3.4 以前の実行中にコード スキャンが使用された場合、データベース テーブルに一意のインデックスを追加しようとすると、その後 3.5 から 3.6 または 3.7 へのアップグレードが失敗する可能性があります。

GitHub Packages が有効になっているインスタンスで、ユーザーがコンテナー レジストリにプッシュした後、インスタンスが要求に対応できる場合に、インスタンスが間違って 429 Too Many Requests エラーで応答しました。 制限が引き上げられました。ユーザーはこのメッセージを受信する頻度を減らす必要があります。 [更新日: 2023 年 5 月 30 日]

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 Enterprise Server の 3.6 シリーズのリリースは、SCIM のテストには適さなくなりました。 SCIM のプライベート ベータ版を引き続き使うには、インスタンスをバージョン 3.7.3 以降にアップグレードしてください。 詳しくは、「GitHub Enterprise Server のアップグレード」をご覧ください。 [更新日: 2023 年 4 月 17 日]

高: 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 で失敗します。

組織が所有するリポジトリが削除された後、組織内のディスカッションの設定ページが 500 エラーを返しました。

GitHub Enterprise Server の 3.6 シリーズのリリースは、SCIM のテストには適さなくなりました。 SCIM のプライベート ベータ版を引き続き使うには、インスタンスをバージョン 3.7.3 以降にアップグレードしてください。 詳しくは、「GitHub Enterprise Server のアップグレード」をご覧ください。 [更新日: 2023 年 4 月 17 日]

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

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

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

GitHub Advanced Security ライセンスを持つインスタンスで、GitHub Enterprise Server 3.4 以前の実行中にコード スキャンが使用された場合、データベース テーブルに一意のインデックスを追加しようとすると、その後 3.5 から 3.6 または 3.7 へのアップグレードが失敗する可能性があります。

GitHub Enterprise Server の 3.6 シリーズのリリースは、SCIM のテストには適さなくなりました。 SCIM のプライベート ベータ版を引き続き使うには、インスタンスをバージョン 3.7.3 以降にアップグレードしてください。 詳しくは、「GitHub Enterprise Server のアップグレード」をご覧ください。 [更新日: 2023 年 4 月 17 日]

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

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

サイト管理者が ghe-config app.gitauth.rsa-sha1 を使って RSA キーによる SSH 接続が許可される最終日を調整した後も、接続試行が SHA-1 ハッシュ関数によって署名されている場合は、インスタンスでは RSA キーによる接続が禁止されます。

構成の実行の検証フェーズ中に、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 イベントの配信は失敗していました。

GitHub Enterprise Server の 3.6 シリーズのリリースは、SCIM のテストには適さなくなりました。 SCIM のプライベート ベータ版を引き続き使うには、インスタンスをバージョン 3.7.3 以降にアップグレードしてください。 詳しくは、「GitHub Enterprise Server のアップグレード」をご覧ください。 [更新日: 2023 年 4 月 17 日]

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

GitHub Enterprise Server の 3.6 シリーズのリリースは、SCIM のテストには適さなくなりました。 SCIM のプライベート ベータ版を引き続き使うには、インスタンスをバージョン 3.7.3 以降にアップグレードしてください。 詳しくは、「GitHub Enterprise Server のアップグレード」をご覧ください。 [更新日: 2023 年 4 月 17 日]

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

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

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

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

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

基になるデータベース テーブルに含まれるレコードが 1 つのみの場合、データ移行が失敗することがありました。

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

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

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

statsd によって解析できない削除された launch.* メトリックにより、結果の statsd エラーによって collectd ログのサイズが急速に増加しました。

カスタム パターンを更新すると、パターンの状態がすぐに発行済みに設定されました。

Redis でのネットワークの問題に対する回復性を高めるため、リアルタイム更新サービス (Alive) の信頼性を向上させました。

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

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

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

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

GitHub Enterprise Server の 3.6 シリーズのリリースは、SCIM のテストには適さなくなりました。 SCIM のプライベート ベータ版を引き続き使うには、インスタンスをバージョン 3.7.3 以降にアップグレードしてください。 詳しくは、「GitHub Enterprise Server のアップグレード」をご覧ください。 [更新日: 2023 年 4 月 17 日]

高: 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 Enterprise Server 3.6 以降へのアップグレードがブロックされました。

サイト管理者は、ロックを解除したリポジトリのセキュリティ製品設定を管理できませんでした。

サイト管理者が管理シェル (SSH) を介してキャッシュ レプリカで ghe-repl-status コマンドを実行すると、コマンドによって、Git と Alambic クラスターのレプリケーションの全体的な状態情報がキャッシュ レプリケーションのみに関連するかのように誤って報告されました。

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

高可用性構成でインスタンスと共にリポジトリ キャッシュを使用する場合、Git クライアントがリポジトリのリモート URL に HTTPS ではなく SSH を使用すると、Git LFS は適切なキャッシュ レプリカ ノードではなくインスタンスプライマリ ノードからオブジェクトをフェッチします。

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

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

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

場合によっては、API を使用した検索で 500 エラーが返される場合があります。

場合によっては、Web インターフェイスでリポジトリを参照するときに、リポジトリに現在のブランチ上の特定の未定義のパスが含まれていないことが、誤ったバナーにより示されました。

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

トリアージ、保守、またはカスタム アクセスを使用して、Organization が所有するプライベート リポジトリのユーザー所有のフォークにコラボレーターを追加すると、500 エラーが発生しました。

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

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

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

DNS レコードに対して DNS プロバイダーによって適用される 63 文字の制限によりドメイン検証が失敗しないようにするために、ドメインの所有権を確認するため、GitHub で生成される TXT レコードが 63 文字に制限されるようになりました。

Enterprise 所有者が Dependabot アラートを有効にすると、GitHub Enterprise Server によってアドバイザリ データの同期がエンキューされ、GitHub.com からの 1 時間ごとの更新が確保されます。

最近アクセスしたリポジトリのユーザーのリストに、削除されたリポジトリが含まれないようになりました。

GitHub Enterprise Server の 3.6 シリーズのリリースは、SCIM のテストには適さなくなりました。 SCIM のプライベート ベータ版を引き続き使うには、インスタンスをバージョン 3.7.3 以降にアップグレードしてください。 詳しくは、「GitHub Enterprise Server のアップグレード」をご覧ください。 [更新日: 2023 年 4 月 17 日]

中: 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 が割り当てられました。

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

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

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

リポジトリ キャッシュ レプリカ ノードへの Git LFS オブジェクトのレプリケーションの詳しい状態が、それらのノードの ghe-repl-status 出力に表示されませんでした。

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

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

CodeQL アクションを使うと、実行注釈に誤った HttpError: Upload not found エラーが含まれました。

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

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

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

場合によっては、インスタンスがアクティブなリポジトリを削除されたリポジトリに置き換える場合があります。

リポジトリ内のオブジェクトの合計数が 5,000 を超えた場合、キャッシュ レプリケーション ポリシーを持つリポジトリ内の Git LFS オブジェクトがキャッシュ レプリカにコピーされないことがありました。

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

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

サイト管理者がまだインスタンスの GitHub Actions を構成していない場合は、コード スキャンを設定するための UI によって、ユーザーに GitHub Actions の構成についてのダイアログが表示されます。

GitHub Enterprise Server の 3.6 シリーズのリリースは、SCIM のテストには適さなくなりました。 SCIM のプライベート ベータ版を引き続き使うには、インスタンスをバージョン 3.7.3 以降にアップグレードしてください。 詳しくは、「GitHub Enterprise Server のアップグレード」をご覧ください。 [更新日: 2023 年 4 月 17 日]

高: 管理コンソールの依存関係を最新のパッチ バージョンに更新しました。これは、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 が出力されました。

履歴を表示したり、GitHub Advisory Database に対する改善を提案したりするリンクにユーザーがアクセスすると、URL が正しくなく、404 エラーが発生しました。

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

高可用性用に構成されたインスタンスでは、ユーザーが以前に削除したリポジトリのレプリケーションが遅れていると、ghe-repl-status が誤って報告しました。

ユーザーがユーザー アカウントに 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 アプリは、スコープを指定されたユーザーからサーバーへのトークンを使って、ユーザー認可ロジックをバイパスし、特権をエスカレートできました。

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

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

場合によっては、collectd で /var/log/collectd.log にメトリック関連のエラーが過剰にログされることがありました。

ghe-repl-node --cache-domain を使ってリポジトリ キャッシュ レプリカ ノードの外部ドメイン名を構成すると、Git LFS キャッシュの有効化を妨げるエラーがコマンドから返されました。

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

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

インスタンスへの着信 SMTP 接続に対して TLS 暗号化を有効にするオプションが、管理コンソールにありませんでした。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GitHub Enterprise Server の 3.6 シリーズのリリースは、SCIM のテストには適さなくなりました。 SCIM のプライベート ベータ版を引き続き使うには、インスタンスをバージョン 3.7.3 以降にアップグレードしてください。 詳しくは、「GitHub Enterprise Server のアップグレード」をご覧ください。 [更新日: 2023 年 4 月 17 日]

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

管理コンソールと /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 へのリンクが、壊れていました。

Organization 所有者は、ディスカッションの作成に必要なアクセスのレベルを設定できませんでした。

ディスカッションのユーザーは、GitHub.com のコミュニティ ガイドラインに誤って誘導されました。

ユーザーは、ディスカッションを作成する前にメールを検証するよう、誤って指示されることがありました。

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

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

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

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

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

REST API を使って閉じることができるよう、グローバル通知バナーを構成できるようになりました。 詳しくは、「Enterprise のユーザメッセージをカスタマイズする」を参照してください。

GitHub Enterprise Server の 3.6 シリーズのリリースは、SCIM のテストには適さなくなりました。 SCIM のプライベート ベータ版を引き続き使うには、インスタンスをバージョン 3.7.3 以降にアップグレードしてください。 詳しくは、「GitHub Enterprise Server のアップグレード」をご覧ください。 [更新日: 2023 年 4 月 17 日]

リポジトリ キャッシュは一般提供されています。 リポジトリ キャッシュは、分散開発者のために Git の読み取りパフォーマンスを向上させ、プッシュ ワークフローに影響を与えることなく geo レプリケーションのデータの局所性と利便性を提供します。 一般提供リリースでは、Git と Git LFS の両方のデータが GitHub Enterprise Server によってキャッシュされます。 詳しくは、「リポジトリのキャッシュについて」を参照してください。

サイト管理者は、RSA キーを使用し、SHA-1 ハッシュ関数によって署名される SSH 経由の Git 操作を許可する期日を構成できます。 既定では、2022 年 8 月 1 日午前 0 時 (UTC) の期日より後にユーザー アカウントに追加された RSA キーのために、これらの接続は失敗します。 詳しくは、非推奨に関する記事をご覧ください。 [更新日: 2023 年 1 月 31 日]

GitHub Enterprise Server では、必要に応じて Ed25519 ホスト キーの公開通知を許可します。 詳しくは、「インスタンスのホスト キーの構成」をご覧ください。

インスタンスへの着信 SMTP 接続に対して、TLS 暗号化を要求できます。 詳しくは、「通知のためのメール設定」をご覧ください。

• 注: この機能は、GitHub Enterprise Server 3.6.0 と 3.6.1 では使用できません。 この機能は 3.6.2 リリースで使用できます。 [更新日: 2022 年 9 月 22 日]

インスタンスに対する監査ログと Git イベントを、Amazon S3、Azure Blob Storage、Azure Event Hubs、Google Cloud Storage、または Splunk にストリーミングできます。 監査ログのストリーミングはパブリック ベータ版であり、変更される可能性があります。 詳細については、「企業の監査ログのストリーミング」を参照してください。

Server Statistics が一般提供されるようになりました。 Server Statistics は、GitHub Enterprise Server インスタンスから集計された使用状況データを収集します。これを使うと、Organization のニーズをより適切に予測し、チームのしくみを理解し、GitHub Enterprise Server から得られる価値を確認できます。 詳細については、「Server Statistics について」を参照してください。

エンタープライズ所有者は、エンタープライズ アカウントの [組織] ページから、インスタンスの組織にメンバーまたは所有者として参加できます。 詳細については、「Enterprise の Organization を管理する」を参照してください。

Enterprise の所有者は、構成されているグローバル アナウンス バナーをユーザーが無視することを許可できます。 詳細については、「エンタープライズのユーザー メッセージをカスタマイズする」を参照してください。

GitHub Advanced Security ライセンスがあるインスタンス上のユーザーは、Organization 所有者またはリポジトリ管理者がコード セキュリティまたは分析機能を有効または無効にするとトリガーする Webhook イベントを受け取ることができます。 詳しくは、次のドキュメントを参照してください。

• Webhook のドキュメントの「Webhook のイベントとペイロード」
• Organization のセキュリティおよび分析設定を管理する
• 「リポジトリのセキュリティと分析設定を管理する」

GitHub Advanced Security ライセンスがあるインスタンス上のユーザーは、Web UI または REST API でコード スキャン アラートを無視するときに、必要に応じてコメントを追加できます。 無視に関するコメントは、イベントのタイムラインに表示されます。 ユーザーは、REST API を使って無視に関するコメントを追加または取得することもできます。 詳細については、「Pull Request で Code scanning アラートをトリアージする」と REST API のドキュメントの「Code Scanning」を参照してください。

GitHub Advanced Security ライセンスがあるインスタンスでは、シークレット スキャンによって Web エディターでのシークレットのリークが防がれます。 詳細については、「Protecting pushes with secret scanning (シークレット スキャンによるプッシュの保護)」を参照してください。

GitHub Advanced Security ライセンスがあるインスタンス上の Enterprise 所有者とユーザーは、Enterprise と Organization の監査ログを見るか、REST API を使うことで、シークレット スキャンのアラートと、シークレット スキャンのプッシュ保護のバイパスを確認できます。 詳しくは、次のドキュメントを参照してください。

• 「シークレット スキャンによるプッシュの保護」
• 「エンタープライズの監査ログ イベント」
• 「Organization の監査ログをレビューする」
• REST API のドキュメントの「シークレット スキャン」

GitHub Advanced Security ライセンスがあるインスタンス上の Enterprise 所有者は、Enterprise 用のカスタム シークレット スキャン パターンのドライ ランを実行でき、すべてのユーザーはパターンを編集するときにドライ ランを実行できます。 ドライ ランを行うと、インスタンス全体へのパターンの影響を理解し、アラートの発行と生成の前にパターンを調整できます。 詳細については、シークレット スキャンのカスタム パターンの定義に関する記事を参照してください。

GitHub Advanced Security ライセンスがあるインスタンス上のユーザーは、シークレット スキャン アラートを取得する REST API で sort と direction パラメーターを使うことができ、アラートの created または updated フィールドを基にして並べ替えることができます。 新しいパラメーターは、インスタンス全体または個別の Organization やリポジトリで利用できます。 詳しくは、次のドキュメントを参照してください。

• 「エンタープライズのシークレット スキャン アラートを一覧表示する」
• 「組織のシークレット スキャン アラートを一覧表示する」
• 「リポジトリのシークレット スキャン アラートを一覧表示する」
• REST API のドキュメントの「シークレット スキャン」

CodeQL でサポートされる他のすべてのプログラミング言語用の同様のライブラリと一緒にするため、github/codeql-go リポジトリのコンテンツを github/codeql リポジトリに移動しました。 GitHub の CodeQL コード分析ツールを使って Go プログラミング言語で書かれたコードベースを分析するためのオープンソースの CodeQL クエリ、ライブラリ、抽出子は、新しい場所で見つかります。 既存のワークフローの移行に関するガイダンスなど、詳細については、github/codeql-go#741 を参照してください。

GitHub Advanced Security ライセンスがあるインスタンス上の Enterprise 所有者は、インスタンス全体についての Dependabot アラートの概要を見ることができます。アプリケーション セキュリティ リスクのリポジトリ中心のビューや、シークレット スキャンと Dependabot のすべてのアラートのアラート中心のビューなどです。 これらのビューはベータ版なので変更される可能性があり、コード スキャンのアラート中心のビューは GitHub Enterprise Server の将来のリリースで計画されています。 詳細については、「Viewing the security overview」(セキュリティの概要の表示) を参照してください。

ユーザーは、複数の Dependabot アラートを選んで、閉じたり、もう一度開いたりできます。 たとえば、 [Closed alerts] (閉じられたアラート) タブで、以前に閉じられた複数のアラートを選んでから、それらをまとめてもう一度開くことができます。 詳細については、「Dependabot アラートについて」を参照してください。

• 注: この機能は、GitHub Enterprise Server 3.6.0 では使用できません。 この機能は、GitHub Enterprise Server 3.7.0 以降で使用できます。 [更新日: 2022 年 10 月 19 日]

Dependabot は、TypeScript プロジェクトの対応するパッケージと共に、@types の依存関係を更新します。 この変更の前に、パッケージとそれに対応する @types パッケージに対する別の pull request が、ユーザーに対して表示されます。 この機能は、package.json ファイル内のプロジェクトの devDependencies に @types パッケージが含まれるリポジトリに対して、自動的に有効にされます。 この動作は、dependabot.yml ファイルの ignore フィールドを @types/* に設定することで無効にできます。 詳しくは、「GitHub Dependabot のバージョンアップデートについて」と「dependabot.yml ファイルの構成オプション」をご覧ください。

GitHub Actions は、依存関係をスキャンすることでユーザーの pull request で依存関係レビューを行うことができ、関連するセキュリティの脆弱性についてユーザーに警告します。 dependency-review-action アクションは、任意の 2 つのリビジョン間で依存関係の差異を調べる新しい API エンドポイントによってサポートされます。 詳細については、「依存関係レビューについて」を参照してください。

依存関係グラフは、Cargo.toml と Cargo.lock ファイルで Rust を検出します。 これらのファイルは、 [分析情報] タブの [Dependency graph] (依存関係グラフ) セクションに表示されます。ユーザーは、Rust の依存関係に関連する脆弱性に関する Dependabot のアラートと更新プログラムを受け取ります。 パッケージからリポジトリへのマッピングなど、パッケージのメタデータは後日追加されます。 詳細については、「依存関係グラフの概要」を参照してください。

インスタンスで GitHub Connect が有効になっている場合、ユーザーは [GitHub Advisory Database] でのセキュリティ アドバイザリの改善に寄与できます。 寄与するには、アドバイザリの詳細を表示している間に、 [Suggest improvements for this vulnerability] (この脆弱性に対する改善の提案) をクリックします。 詳細については、次の記事を参照してください。

• 「GitHub Connect の管理」
• GitHub Enterprise Cloud のドキュメントの「GitHub Advisory Database のセキュリティ脆弱性を参照する」
• GitHub Enterprise Cloud のドキュメントの「リポジトリの GitHub セキュリティ アドバイザリについて」
• GitHub Enterprise Cloud のドキュメントの「GitHub Advisory Database でのセキュリティ アドバイザリの編集」

再利用可能なワークフローを呼び出すワークフロー内で、ユーザーは secrets: inherit を使って再利用可能なワークフローにシークレットを渡すことができます。 詳細については、「ワークフローの再利用」を参照してください。

GitHub Actions を使うとき、別のユーザーによってレビューされていない変更が保護されたブランチにマージされるリスクを減らすため、Enterprise 所有者とリポジトリ管理者は、Actions によって pull request が作成されないようにすることができます。 これまで、Organization 所有者はこの制限を有効にできました。 詳細については、次の記事を参照してください。

• 「エンタープライズで GitHub Actions のポリシーを適用する」
• 「組織について GitHub Actions を無効化または制限する」
• 「リポジトリの GitHub Actions の設定を管理する」

ユーザーは、workflow_dispatch と workflow_call によってトリガーされる単一のワークフローを作成し、inputs コンテキストを使って入力値にアクセスすることができます。 これまでは、workflow_dispatch の入力はイベント ペイロードの中にあり、再利用可能であると共に手動でトリガーされる 1 つのワークフローを作成しようとするワークフロー作成者にとって、難しさが増していました。 workflow_dispatch によってトリガーされるワークフローの場合は、互換性を保つため、引き続き github.event.inputs コンテキストで入力を利用できます。 詳細については、「コンテキスト」を参照してください。

ジョブの結果を要約するため、ユーザーは Markdown を生成し、ジョブの概要として内容を発行できます。 たとえば、GitHub Actions でテストを実行した後、合格または不合格になったテストやスキップされたテストの概要を提供でき、完全なログ出力を確認する必要性が減る可能性があります。 詳細については、「GitHub Actions のワークフロー構文」を参照してください。

ワークフローの再実行の間にジョブの実行の失敗をいっそう簡単に診断するため、ユーザーはデバッグ ログを有効にできます。これにより、ジョブの実行と環境に関する情報が出力されます。 詳細については、「ワークフローとジョブの再実行」と「ワークフロー実行ログの使用」を参照してください。

GitHub Actions 用のセルフホステッド ランナーを管理する場合、実行するスクリプトを定義することで、ワークフローの実行の前と後に、ランナー自体が一貫した状態であることを確認できます。 スクリプトを使うことで、これらの手順をワークフローに手作業で組み込むことをユーザーに求める必要がなくなります。 ジョブの前と後のスクリプトはベータ版であり、変更される可能性があります。 詳細については、「ジョブの前または後にスクリプトを実行する」を参照してください。

Enterprise 所有者は、コンテナー イメージを GitHub Docker レジストリから GitHub Container レジストリに移行できます。 コンテナー レジストリには、次の利点があります。

• Organization 内でのコンテナーの共有を向上させる
• アプリケーションにきめ細かいアクセス許可を付与する
• パブリック コンテナー イメージの匿名共有を許可する
• Docker イメージをホストするための OCI 標準を実装する

コンテナー レジストリはベータ版であり、変更される可能性があります。 詳細については、「Docker レジストリからコンテナー レジストリへの Enterprise の移行」を参照してください。

GitHub Discussions は GitHub Enterprise Server で利用できます。 GitHub Discussions は、質問し、アイデアを共有し、関係を築くための集まりの場になります。 詳細については、「GitHub Discussions」を参照してください。

Enterprise 所有者は、内部リポジトリまたはパブリック リポジトリにユーザーのユーザー名またはフル ネームが表示されるかどうかを制御するためのポリシーを構成できます。 詳細については、「Enterprise でリポジトリ管理ポリシーを適用する」を参照してください。

ユーザーは、Organization 用にメンバー専用の README を作成できます。 詳細については、「組織のプロファイルのカスタマイズ」を参照してください。

組織所有者は、新しい [Pin repository] (リポジトリのピン留め) ドロップダウンを使って、リポジトリから直接組織のプロファイルにリポジトリをピン留めすることができます。 ピン留めされたパブリック リポジトリは、インスタンスのすべてのユーザーに表示されます。一方、パブリック、プライベート、内部リポジトリは、Organization のメンバーだけに表示されます。

フォークを作成するとき、ユーザーはフォークの名前をカスタマイズできます。 詳細については、「リポジトリのフォーク」を参照してください。

ユーザーは、開かれた pull request に関連付けられているブランチを削除できます。 詳細については、「リポジトリ内でブランチを作成および削除する」を参照してください。

複数のライセンスがあるリポジトリでは、 [コード] タブの [バージョン情報] サイドバーに、すべてのライセンスが表示されます。詳細については、「リポジトリのライセンス」を参照してください。

ユーザーは、他のユーザーに、ブランチに関連付けられた pull request をマージする前に、ブランチを正常にデプロイすることを要求できます。 詳細については、「保護されたブランチについて」と「ブランチ保護ルールを管理する」を参照してください。

Enterprise 所有者は、Organization 所有者がインスタンスのリポジトリにコラボレーターを招待することを禁止できます。 詳細については、外部コラボレーターをリポジトリに招待するためのポリシーの適用に関する記事を参照してください。

ユーザーは、例外をサポートするブランチ保護ルールについて、GitHub Apps に対する例外を許可できます。 詳細については、「アプリについて」と「ブランチ保護ルールを管理する」を参照してください。

期限切れまたは取り消し済みのパブリック GPG 署名キーについて、GitHub Enterprise Server は、Git コミットの署名を検証し、キーがまだ有効な間にユーザーがコミットを行った場合は、コミットを検証済みとして表示します。 ユーザーは、期限切れまたは取り消し済みの GPG キーをアップロードすることもできます。 詳細については、「コミット署名の検証について」を参照してください。

リポジトリを管理するルールとライセンスにコミットが準拠していることを確認するため、Organization 所有者とリポジトリ管理者は、開発者に、Web インターフェイスから行われるコミットにサインオフすることを要求できるようになりました。 詳細については、「Organization のコミット サインオフ ポリシーの管理」と「リポジトリのコミット サインオフ ポリシーを管理する」を参照してください。

pull request の [Files changed] (変更されたファイル) タブにあるファイル ツリーを使って、ユーザーは変更されたファイルの間を移動し、変更のサイズとスコープを理解し、レビューに注目することができます。 pull request で少なくとも 2 つのファイルが変更され、ブラウザーのウィンドウに十分な幅がある場合、ファイル ツリーが表示されます。 詳しくは、「pull request で提案された変更をレビューする」と「pull request 内のファイルをフィルタリングする」をご覧ください。

ユーザーは、すべてのスカッシュ マージに対するコミット メッセージとして、pull request のタイトルを既定で使うことができます。 詳細については、「pull request にコミットのスカッシュを構成する」を参照してください。

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

特定のリリースについての詳細を表示するとき、ユーザーは、各リリース アセットの作成日を見ることができます。 詳細については、「リポジトリのリリースとタグを表示する」を参照してください。

自動生成されるリリース ノートを使ってリリースを作成するとき、ユーザーは、以前のリリースとして示されるタグを確認してから、異なるタグを選んで、以前のリリースとして指定することができます。 詳細については、「自動生成リリース ノート」を参照してください。

Web インターフェイスでの Markdown の編集が改善されました。

• ユーザーがテキストを選んで URL を貼り付けた後、選ばれたテキストは、貼り付けられた URL への Markdown リンクになります。
• ユーザーがスプレッドシートのセルまたは HTML のテーブルを貼り付けると、結果のテキストはテーブルとしてレンダリングされます。
• ユーザーがリンクを含むテキストをコピーすると、貼り付けられたテキストに含まれるリンクは Markdown リンクになります。

詳細については、「基本的な書き方とフォーマットの構文」を参照してください。

Markdown ファイルを Web インターフェイスで編集しているとき、 [プレビュー] タブをクリックすると、編集していた場所にプレビューが自動的にスクロールします。 スクロールする場所は、 [プレビュー] タブをクリックする前のカーソルの位置に基づきます。

暗号化されていない、認証されていない Git プロトコルは、既定で無効になりました。 GitHub Enterprise Server 3.6 以降にアップグレードした後にプロトコルをもう一度有効にしなければ、ポート 9418 での git:// 接続を行うと、次のエラーが返されます。

The unauthenticated git protocol on port 9418 is no longer supported.

環境内でプロトコルをサポートする場合は、この機能を手動でもう一度有効にする必要があります。 詳しくは、「Enterprise でリポジトリ管理ポリシーを適用する」と「GitHub ブログ」をご覧ください。 [更新日: 2023 年 1 月 31 日]

Web インターフェイス内のリンクやボタンなどの対話型要素は、キーボードでフォーカスを設定するとアウトラインが表示され、ページ上で現在位置を見つけるのに役立ちます。 さらに、フォーカスを設定すると、フォーム フィールドの枠線のコントラストが高くなります。

新しい issue または pull request の作成中にページを最新の情報に更新する場合、担当者、レビュー担当者、ラベル、プロジェクトはすべてそのままになります。

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

GitHub Enterprise Server の 3.6 シリーズのリリースは、SCIM のテストには適さなくなりました。 SCIM のプライベート ベータ版を引き続き使うには、インスタンスをバージョン 3.7.3 以降にアップグレードしてください。 詳しくは、「GitHub Enterprise Server のアップグレード」をご覧ください。 [更新日: 2023 年 4 月 17 日]

GitHub Enterprise Server インスタンスをセットアップしたばかりでユーザーがいない場合、攻撃者が最初の管理者ユーザーを作成できました。

カスタムのファイアウォール規則は、アップグレード プロセス中に削除されます。

Web インターフェイス経由でアップロードされた Git LFS 追跡ファイルが、誤ってリポジトリに直接追加されます。

GitHub Connect で [Users can search GitHub.com](ユーザーが GitHub.com を検索できる) が有効になっている場合、プライベートと内部リポジトリのイシューが GitHub.com の検索結果に含まれません。

GitHub Packages npm レジストリが、メタデータ応答で時刻値を返さなくなります。 これは、パフォーマンスの大幅な向上を可能にするために行われました。 メタデータ応答の一部として時刻値を返すために必要なすべてのデータを引き続き保持します。また、既存のパフォーマンスの問題を解決したら、将来的にはこの値を再び返す予定です。

pre-receive フックの処理に固有のリソース制限が、一部の pre-receive フックのエラーを引き起こす場合があります。

別のホストで作成されたバックアップからインスタンスを復元した後、Actions のサービスを再起動する必要があります。

リポジトリの設定で、読み取りアクセス権を持つユーザーにディスカッションの作成を許可するオプションを有効にしても、この機能は有効になりません。

ユーザーが既存の issue をディスカッションに変換できない場合があります。

シークレット スキャンのカスタム パターンの末尾の区切り記号は .* です (具体的には [シークレットの後] フィールド)。 この区切り記号のためにリポジトリ間でのシークレットのスキャンで不整合が発生し、リポジトリの履歴にスキャンが完了していないギャップができる場合があります。 増分スキャンも影響を受ける場合があります。 スキャンでの問題を避けるには、パターンの末尾を変更して、.* 区切り記号を削除します。

GitHub Advanced Security をご利用のお客様が GitHub Enterprise Server 3.6 にアップグレードすると、Web UI と REST API で、シークレット スキャンからのアラートが表示されなくなることがあります。 以前と同様にアラートが表示されるようにするには、最新リリースにアップグレードするときに 3.4 をスキップしないでください。 3.4 を介したアップグレードを計画する場合は、アップグレード アシスタントに関する記事を参照してください。

• 組織が所有するすべてのリポジトリについて、欠落しているアラートを表示するには、組織所有者が組織の [Code security and analysis](コードのセキュリティと分析) 設定に移動し、シークレット スキャンについて [Enable all](すべて有効にする) をクリックします。 詳しくは、「Organization のセキュリティおよび分析設定を管理する」を参照してください。
• 個々のリポジトリについて、欠落しているアラートを表示するには、そのリポジトリに対して管理者アクセス権を持つユーザーがリポジトリのシークレット スキャンを無効にしてから、有効にします。 詳しくは、「リポジトリのセキュリティと分析設定を管理する」を参照してください。

修正プログラムは、3.6.1 パッチ リリースで入手できます。 [更新日: 2022-09-01]

レプリカ ノードを GitHub Enterprise Server 3.6.0 以降にアップグレードし、レプリケーションを再起動すると、Git レプリケーションの進行が停止し、WARNING: git replication is behind the primary … が表示され続ける場合があります。 この既知の問題が発生する場合は、GitHub Enterprise サポート にお問い合わせください。 [更新日: 2022 年 10 月 3 日]

GitHub Pages のビルドが、高可用性用に構成された AWS のインスタンスでタイムアウトする場合があります。 [更新日: 2022 年 11 月 28 日]

Git 要求の同時実行数が多いインスタンスでは、パフォーマンスの問題が発生する可能性があります。 この問題がご自分のインスタンスに影響していると思われる場合は、GitHub Support にお問い合わせください。 詳しくは、「サポートチケットの作成」を参照してください。 [更新日: 2022-12-07]

高可用性構成のインスタンスでは、次の状況で git push の操作に失敗することがあります。 [更新日: 2023 年 3 月 17 日]

• レプリカ ノードでのリポジトリ作成時
• レプリカ ノードでリポジトリの作成に失敗した後、リポジトリの自動修復を行う前

An upgrade to GitHub Enterprise Server 3.6 or 3.7 from 3.5 or earlier may be long running if a large number of deleted repositories exist. Deleted repositories are purged automatically after 90 days, but for a faster upgrade they can be purged manually. If you suspect you have thousands of recently deleted repositories, and you are concerned about a long running upgrade, contact GitHub Enterprise Support for assistance purging deleted repositories. [Updated: 2023-05-09]