Enterprise Server 3.7 release notes

MEDIUM: Scoped installation tokens for a GitHub App kept approved permissions after the permissions on the integration installation were downgraded or removed. GitHub has requested CVE ID CVE-2023-23765 for this vulnerability, which was reported via the GitHub Bug Bounty program.

Packages have been updated to the latest security versions.

On an instance in a cluster configuration, when upgrading the MySQL master node, the post-upgrade configuration run would take 600 seconds longer than required due to incorrect detection of unhealthy nodes.

In some situations on an instance with multiple nodes, Git replication failed to fully replicate repositories that had previously been deleted, which resulted in a warning in ghe-repl-status output.

On an instance with the dependency graph enabled, the correct path appears for manifests that originate from build-time submission snapshots.

People with administrative SSH access to an instance can configure the maximum memory usage in gigabytes for Redis using ghe-config redis.max-memory-gb VALUE.

HIGH: Updated Git to include fixes from 2.39.2, which address CVE-2023-22490 and CVE-2023-23946.

MEDIUM: Updated Git to include fixes from 2.40.1. For more information, see Git security vulnerabilities announced on the GitHub Blog.

Users were unable to upload GIF files as attachments within a comment in an issue or pull request.

On an instance in a high availability configuration, a git push operation could fail if GitHub Enterprise Server was simultaneously creating the repository on a replica node.

A site administrator could not bypass a proxy for a top-level domain (TLD) from the instance's exception list or IANAs registered top-level domains (TLDs).

On some platforms, after someone with administrative SSH access ran ghe-diagnostics, the command's output included a cosmetic SG_IO error.

In some cases on an instance with a GitHub Advanced Security license, users could not load the security analysis page and saw a 500 error.

When a site administrator used GitHub Enterprise Importer to import data from GitHub Enterprise Cloud, migrations failed during the import of file-level comments. This failure no longer prevents the import from proceeding.

On an instance with a GitHub Advanced Security license, users with the security manager role for an organization could not view GitHub Advanced Security settings for the organization.

If a user clicked the link to share feedback or report bugs for the beta of user lists, the web interface responded with a 404 error.

When a site administrator used GitHub Enterprise Importer, import of a repository failed if a project column in the repository contained 2,500 or more archived cards.

On an instance with Dependabot alerts enabled, alerts were erroneously hidden when different vulnerabilities were detected by multiple build-time submission detectors.

GitHub Enterprise Server published distribution metrics that cannot be processed by collectd. The metrics included pre_receive.lfsintegrity.dist.referenced_oids, pre_receive.lfsintegrity.dist.unknown_oids, and git.hooks.runtime.

In some cases, on an instance with GitHub Actions enabled, deployment of GitHub Pages site using a GitHub Actions workflow failed with a status of deployment_lost.

On an instance with a GitHub Advanced Security license that was also configured for a timezone greater than UTC, the list of secret scanning alerts displayed a "Loading secrets failed" error if a user sorted secrets by date in descending order.

On an instance with the dependency graph enabled, background services can handle more traffic.

People with administrative SSH access who generate a support bundle using the ghe-support-bundle or ghe-cluster-support-bundle utilities can specify the period of time to gather data with -p or --period without using spaces or quotes. For example, in addition to '-p 5 days' or -p '4 days 10 hours', -p 5days or -p 4days10hours are valid.

GitHub Actions が有効になっているインスタンスでは、マトリックスを使用した再利用可能なワークフロー ジョブ内の再利用可能なワークフローへの入れ子になった呼び出しによって、strategy: ${{ inputs.strategies }} などの式内のコンテキストが正しく評価されます。

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

GitHub Connect と GitHub.com アクションへの自動アクセスの両方が有効になっているインスタンスの場合、Dependabot は GitHub.com でホストされているアクションを更新できません。

GitHub Advanced Security ライセンスを持つインスタンスで、ユーザーがセキュリティ分析ページを読み込めず、500 エラーが表示される場合がありました。

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

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

kredz.* メトリックが含まれているため、収集されたログはサイズが急激に増加する可能性があり、StatsD では解析できず、エラー メッセージが発生します。

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

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

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

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

GitHub Actions が有効になっているインスタンスでは、マトリックスを使用した再利用可能なワークフロー ジョブ内の再利用可能なワークフローへの入れ子になった呼び出しによって、strategy: ${{ inputs.strategies }} などの式内のコンテキストが正しく評価されます。

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

管理コンソールのモニター ダッシュボードでは、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) が、インスタンスのモニター ダッシュボード内のプロセス リストに表示されませんでした。

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

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

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

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

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

GitHub Enterprise Server の SCIM のプライベート ベータ版を使用するように構成されたインスタンスでは、承認の誤った要件により、SSH キーと個人用アクセス トークンでのユーザーの認証が失敗しました。

プッシュ保護が有効になっているリポジトリをユーザーがインポートした後、そのリポジトリはセキュリティの概要の [セキュリティ カバレッジ] ビューにすぐには表示されませんでした。

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

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

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

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

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

場合によっては、複数のノードがあるインスタンスで、GitHub Enterprise Server により、レプリカ ファイル サーバーへの書き込みが誤って停止され、リポジトリ データが同期されなくなりました。

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 へのアップグレードが失敗する可能性があります。

どのエンタープライズ所有者もユーザー アカウントの 2 要素認証 (2FA) を有効にしていなかった場合、エンタープライズ所有者はインスタンスの 2FA を有効にすることができませんでした。 [更新日: 2023 年 4 月 17 日]

Dependency Submission REST API により、バージョンのない 1 つまたは複数の依存関係を含む申請が受け取られたときに、依存関係グラフでこの事実が正しく報告されるようになります。

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

クラスター構成のインスタンスで、サイト管理者が 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 Pages のサイトをビルドする際に、任意のファイルの読み取りを許可するパス トラバーサルの脆弱性が GitHub Enterprise Server で特定されました。 攻撃者がこの脆弱性を悪用するには、インスタンス上に GitHub Pages サイトを作成してビルドするためのアクセス許可が必要です。 この脆弱性は GitHub バグ報奨金プログラムを通じて報告され、CVE-2023-22380 が割り当てられています。

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

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

GitHub Connect と GitHub.com アクションへの自動アクセスの両方が有効になっているインスタンスの場合、Dependabot は GitHub.com でホストされているアクションを更新できません。

インスタンスに GitHub Advanced Security ライセンスがない場合、GitHub Advanced Security 共同作成者に関する詳細情報を含む CSV ファイルをダウンロードできません。

kredz.* メトリックが含まれているため、収集されたログはサイズが急激に増加する可能性があり、StatsD では解析できず、エラー メッセージが発生します。

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

Dependency Submission REST API が、バージョンのない 1 つ以上の依存関係を含む申請を受け取ると、依存関係グラフはこの事実を正しく報告するようになります。

中: 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 が発生している可能性があります。

Dependabot の更新を無効にすると、Dependabot のアバターは @ghost ユーザーとして Dependabot アラート タイムラインに表示されました。

一部のケースで、アクティブなコミッターの数が非常に多いインスタンスの [Code security & analysis] (コード セキュリティおよび分析) 設定ページを表示するときに、500 エラーが発生することがありました。

GitHub サポートに問い合わせるためのリンク、または GitHub Enterprise Server のリリース ノートを表示するためのリンクが一部正しくありませんでした。

GitHub Advanced Security の追加のコミッター数が、常に 0 と表示されました。

一部のケースで、ユーザーが既存のイシューをディスカッションに変換できない場合がありました。 ディスカッションへの変換中にイシューが停止した場合、エンタープライズ所有者は、以下の「既知の問題」セクションで詳細を確認できます。

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

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

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

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

一部のサービスが、内部プロキシを経由せず、誤って kafka-lite に直接接続されていました。 Web サービスとジョブ サービスが個別のノードで実行されるクラスター環境で、Insights ジョブ サービスから生成されたメッセージが kafka-lite に配信されていませんでした。

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

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

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

組織レベルでのシークレット スキャン用のカスタム パターン一覧の並べ替えとフィルター処理が正しく機能していませんでした。

GitHub Enterprise Server 3.7 にアップグレードした後、組織またはリポジトリのセキュリティ設定ページを表示したときに、アップグレードの開始前に GitHub Advanced Security のバックフィル ジョブが完了しなかったために 500 エラーが発生することがありました。

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

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

競合状態により、サイト管理者がアップグレードを再試行するまで、GitHub Enterprise Server 3.6 以降へのアップグレードがブロックされました。

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

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

高可用性構成で、レプリカをプライマリ ノードに昇格した後、サイト管理者は ghe-repl-stop -f コマンドを使ってセカンダリ レプリカ ノードでレプリケーションを強制的に停止できませんでした。

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

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

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

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

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

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

特定の文字を含む Dependabot アラートを無視すると、400 エラーが発生する可能性がありました。

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

認証に SAML を使うインスタンスでは、個人用アクセス トークンと SSH キーに対する [SSO の構成] ドロップダウン メニューの表示が誤っていました。

削除されたリポジトリがインスタンスでまだ消去されていないため、GitHub Enterprise Server 3.5 から 3.7 へのアップグレードが失敗することがありました。

高可用性またはリポジトリ キャッシュの構成で、プライマリ ノード以外のノードの Unicorn サービスが、プライマリ ノードにログ イベントを送信できませんでした。

GHES ログ ファイルが非常に短期間でいっぱいになり、ルート ドライブの空き領域が不足する可能性があるバグを修正しました。

Ruby のコード スキャン結果を表示すると、誤ったベータ版ラベルが表示されました。

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

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

SCIM for GitHub Enterprise Server のプライベート ベータに参加している場合、SAML ユーザー属性のカスタム マッピングがサポートされるようになりました。 カスタム マッピングを使うと、SAML 認証時に一意の識別要求として NameID 以外の値を使用できます。 詳しくは、「Enterprise 用の SCIM を使用したユーザーのプロビジョニングを構成する」を参照してください。 [更新日: 2023 年 2 月 27 日]

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

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

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

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

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

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

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

構成の実行の検証フェーズ中に、Notebook と Viewscreen のサービスで No such object エラーが発生する可能性があります。 サービスが引き続き正しく起動するため、このエラーは無視することができます。

GitHub Enterprise Server 3.6 以降へのアップグレード後、破損した参照やオブジェクトの欠落など、既存のリポジトリ内の不整合が、invalid sha1 pointer 0000000000000000000000000000000000000000、Zero-length loose reference file、Zero-length loose object file のようなエラーとして報告される可能性があります。 以前は、リポジトリの破損に関するこれらのインジケーターは、暗黙的に無視されていた可能性があります。 GitHub Enterprise Server では、より入念なエラー報告が有効にされた、更新された Git バージョンが使用されるようになりました。 詳しくは、Git プロジェクトのこちらのアップストリームのコミットをご覧ください。

このような問題がお使いのリポジトリのいずれかに存在すると思われる場合は、GitHub Enterprise サポートにお問い合わせください。

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

TLS とサブドメイン分離が有効になっているインスタンスでドメイン設定を検証する場合、管理コンソールには、GitHub Enterprise Server 3.7 の 2 つの新しいサブドメイン http(s)://notebooks.HOSTNAME と http(s)://viewscreen.HOSTNAME がドメインのリストに表示されません。 [更新日: 2023 年 1 月 12 日]

SCIM for GitHub Enterprise Server のプライベート ベータに参加している場合、personal access token または SSH キーを使った REST API 以外のリソースへの要求の認証が成功しない場合があります。 修正プログラムは、今後リリースされる GitHub Enterprise Server で使用できるようになる予定です。 [更新日: 2023 年 2 月 27 日]

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

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

高可用性構成のインスタンスでは、サイト管理者はインスタンスがメンテナンス モードになっている間のみ ghe-repl-start と ghe-repl-stop コマンドを実行する必要があります。 詳細については、「メンテナンスモードの有効化とスケジューリング」および「High Availability設定について」を参照してください。 [更新日: 2023 年 3 月 17 日]

高: GitHub Enterprise Server において、コマンドの引数区切りの不適切な無効化により、リモートでコードが実行される脆弱性が確認されました。 この脆弱性を悪用するには、GitHub Actions を使用して GitHub Pages を作成およびビルドするアクセス許可が攻撃者に必要です。 このバグは、もともと GitHub のバグ報奨金プログラムを通じて報告され、CVE-2022-23740 が割り当てられました。 [更新日: 2022 年 12 月 2 日]

高: 任意のファイル上書きバグを防ぐために、新しいコンテンツをアンパックする前に作業ディレクトリがクリーンであることを確認するためのチェックが Pages 内に追加されました。 この脆弱性には、CVE-2022-46255 が割り当てられています。

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

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

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

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

ghe-spokesctl コマンドを実行すると failed to get repo metrics エラーが返されました。

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

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

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

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

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

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

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

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

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

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

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

GitHub Packages が構成されているインスタンスでは、AWS S3 BLOB ストレージの VPC エンドポイント URL を使用しているお客様の、パッケージのアップロードとインストールが失敗するおそれがありました。

場合によっては、GitHub Enterprise Server 3.7.0 にアップグレードした後、SSH または HTTPS 経由で Git 操作を開始するときにユーザーが Internal Server Error または 500 エラーが発生することがあります。

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

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

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

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

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

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

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

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

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

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

構成の実行の検証フェーズ中に、Notebook と Viewscreen のサービスで No such object エラーが発生する可能性があります。 サービスが引き続き正しく起動するため、このエラーは無視することができます。

GitHub Enterprise Server 3.6 以降へのアップグレード後、破損した参照やオブジェクトの欠落など、既存のリポジトリ内の不整合が、invalid sha1 pointer 0000000000000000000000000000000000000000、Zero-length loose reference file、Zero-length loose object file のようなエラーとして報告される可能性があります。 以前は、リポジトリの破損に関するこれらのインジケーターは、暗黙的に無視されていた可能性があります。 GitHub Enterprise Server では、より入念なエラー報告が有効にされた、更新された Git バージョンが使用されるようになりました。 詳しくは、Git プロジェクトのこちらのアップストリームのコミットをご覧ください。

このような問題がお使いのリポジトリのいずれかに存在すると思われる場合は、GitHub Enterprise サポートにお問い合わせください。

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

TLS とサブドメイン分離が有効になっているインスタンスでドメイン設定を検証する場合、管理コンソールには、GitHub Enterprise Server 3.7 の 2 つの新しいサブドメイン http(s)://notebooks.HOSTNAME と http(s)://viewscreen.HOSTNAME がドメインのリストに表示されません。 [更新日: 2023 年 1 月 12 日]

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

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

高可用性構成のインスタンスでは、サイト管理者はインスタンスがメンテナンス モードになっている間のみ ghe-repl-start と ghe-repl-stop コマンドを実行する必要があります。 詳細については、「メンテナンスモードの有効化とスケジューリング」および「High Availability設定について」を参照してください。 [更新日: 2023 年 3 月 17 日]

管理コンソールのセキュリティを強化するために、サイト管理者は、サインイン試行のレート制限と、レート制限を超えた後のロックアウト期間を構成できます。 詳しくは、「Configuring rate limits (レート制限を構成する)」を参照してください。

管理コンソールの最小パスワード要件は、いっそう厳しくなります。

管理コンソールに対する認証の試みと、管理コンソール内でサイト管理者によって行われた変更は、/var/log/enterprise-manage/audit.log のログ ファイルに書き込まれます。

MapBox に代わる Azure Maps は、GeoJSON ファイルをグラフィカル マップとしてレンダリングするためのものです。 管理者は、マップのレンダリングを有効にして、管理コンソールで Azure Maps のトークンを提供できます。 詳しくは、「管理コンソールからのインスタンスの管理」をご覧ください。

ユーザーは、SSH 公開キーを使ってコミットを検証できます。 詳細については、「コミット署名の検証について」を参照してください。

サイト管理者は、SCIM を使って GitHub Enterprise Server インスタンス上のユーザーとグループを自動的にプロビジョニングできます。 GitHub Enterprise Server 用の SCIM はプライベート ベータ版であり、変更される可能性があります。 詳細については、「Enterprise 用の SCIM を使用したユーザーのプロビジョニングを構成する」と、REST API ドキュメントの「SCIM」を参照してください。

GitHub Advanced Security ライセンスがあるインスタンスのユーザーは、pull request の [会話] タブで、リポジトリ内のコード スキャン アラートを表示したり、それにコメントしたりできます。リポジトリに対して [Require conversation resolution before merging] (マージ前に会話の解決必須) ブランチ保護ルールが有効になっている場合は、ユーザーが pull request をマージする前に、これらのコード スキャン アラートに関するすべてのコメントを解決する必要があります。 詳細については、「コード スキャンについて」、「pull request レビューについて」、「保護されたブランチについて」を参照してください。

数十、数百、数千の組織でのインスタンスのシークレット スキャンのロールアウトを簡単にするため、GitHub Advanced Security ライセンスがあるインスタンスのエンタープライズ所有者は、Web インターフェイスを使ってインスタンスのシークレット スキャンとプッシュ保護を有効にできます。 詳細については、「Enterprise 用の GitHub Advanced Security 機能の管理」を参照してください。

GitHub Advanced Security ライセンスがあるインスタンスの組織所有者は、組織内のすべてのリポジトリに対するシークレット スキャンのカスタム パターンのドライ ランを実行できます。 詳細については、シークレット スキャンのカスタム パターンの定義に関する記事を参照してください。

サイト管理者が GitHub Advanced Security ライセンスがあるインスタンスのメール通知を有効にした場合、共同作成者がプッシュ保護によってブロックされたシークレットをバイパスすると、リポジトリのシークレット スキャン アラートを監視するユーザーはメール通知を受け取ります。 以前は、シークレットが擬陽性としてマークされている場合、またはテストで使われている場合は、通知は送信されませんでした。 詳細については、「シークレット スキャンによるプッシュの保護」と「通知のためのメール設定」を参照してください。

シークレット スキャン用の数十または数百のカスタム パターンの管理を容易にするため、GitHub Advanced Security ライセンスがあるインスタンスのユーザー、組織所有者、またはエンタープライズ所有者は、リポジトリ、組織、またはインスタンス全体のパターンの一覧を並べ替えてフィルター処理できます。 詳細については、シークレット スキャンのカスタム パターンの定義に関する記事を参照してください。

GitHub Advanced Security ライセンスがあるインスタンスで、シークレット スキャンに関するプッシュを保護するユーザーは、プッシュ保護によって潜在的なシークレットが検出されてブロックされたときにエラー メッセージに表示されるカスタム リンクを指定できます。 詳細については、「Protecting pushes with secret scanning (シークレット スキャンによるプッシュの保護)」を参照してください。

ユーザーは、CodeQL パックをコンテナー レジストリに発行できます。 詳細については、CodeQL CLI のドキュメントの「CodeQL パックの作成と使用」を参照してください。

GitHub Advanced Security ライセンスがあるインスタンスのユーザーは、コード スキャンで CodeQL パックを使用できます。これには、インスタンスの GitHub コンテナー レジストリに発行されたパックが含まれます。 詳細については、コード スキャンの構成に関する記事と、CodeQL CLI のドキュメントの「CodeQL パックの発行と使用」を参照してください。

GitHub Advanced Security ライセンスがあるインスタンスのユーザーは、クエリ フィルターを使って、コード スキャンに不要な CodeQL クエリを除外できます。 詳細については、「Code scanning を設定する」を参照してください。

GitHub Advanced Security ライセンスがあるインスタンスのエンタープライズ所有者は、REST API を使ってインスタンス全体のコード スキャン結果を取得できます。 新しいエンドポイントは、リポジトリと組織の既存のエンドポイントを補完します。 詳細については、REST API ドキュメントの「コード スキャン」を参照してください。

GitHub Advanced Security ライセンスがあるインスタンスの組織所有者は、REST API を使って、次の機能の有効化状態を取得したり、自動有効化を構成したりできます。

• GitHub Advanced Security
• シークレット スキャン
• プッシュ保護

詳細については、REST API のドキュメントの「Organization」を参照してください。

GitHub Advanced Security ライセンスがあるインスタンスのユーザーは、カーソルを使って、REST API の組織およびリポジトリ エンドポイントで取得されたシークレット スキャン アラートの結果をページ分割できます。 詳しくは、REST API ドキュメントの「シークレット スキャン」を参照してください。

インスタンスのセキュリティの概要には、Dependabot に関する情報が含まれています。 詳細については、「Viewing the security overview」(セキュリティの概要の表示) を参照してください。

ユーザーは、Dependabot アラートに関連付けられているアクティビティの詳細を確認できます。 Dependabot アラートの詳細では、ユーザーは、アラートが開かれた、修正された、または再度開かれたときなど、イベントのタイムラインを確認できます。 イベントでは、わかる場合は、関連する pull request などの追加のメタデータも示されます。 詳細については、「Dependabot アラートについて」を参照してください。

ユーザーの Dependabot アラートは、既定で重要度で並べ替えられます。 重要度では、CVSS が主な要因と見なされ、潜在的なリスク、関連性、脆弱性の修正の容易さも考慮されます。 計算は時間が経つにつれて改善されます。

ユーザーは、依存関係のスコープ (実行時または開発) で Dependabot アラートを並べ替えることができます。

ユーザーは、必要に応じて、Dependabot アラートを無視するときにコメントを追加できます。 無視コメントは、イベント タイムラインと、GraphQL API の RepositoryVulnerabilityAlert オブジェクトの dismissComment フィールドに表示されます。 GraphQL API の詳細については、GraphQL API のドキュメントの「オブジェクト」を参照してください。

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

インスタンスの組織所有者は、REST API を使って、依存関係管理に関する次の機能の有効化状態を取得したり、自動有効化を構成したりできます。

• 依存関係グラフ
• Dependabot アラート
• Dependabot セキュリティ アップデート

詳細については、REST API のドキュメントの「Organization」を参照してください。

エンタープライズ所有者、組織所有者、セキュリティ マネージャーは、インスタンス全体のリスクの一元的なビューにアクセスできます。 このビューには、すべてのコード スキャン、シークレット スキャン、Dependabot アラートのアラート中心のビューも含まれています。 エンタープライズ所有者は、自分が所有者である組織のアラートを表示できます。 組織所有者とセキュリティ マネージャーは、フル アクセス権を持っている組織のリポジトリとアラートを表示できます。 詳細については、「セキュリティの概要について」を参照してください。

組織所有者は、REST API を使ってセキュリティ マネージャーのチームを管理できます。 詳細については、REST API のドキュメントの「セキュリティ マネージャー」を参照してください。

ユーザーは、GitHub Advisory Database に対して次の機能強化を利用できます。

• データベースには、Elixir、Erlang の Hex パッケージ マネージャー、その他のアドバイザリが表示されます。
• ユーザーは、type:malware を検索することで、マルウェアのアドバイザリを見つけることができます。
• データベースには、GitHub Actions の脆弱性に関するアドバイザリが表示されます。

詳細については、「GitHub Advisory Database のセキュリティ アドバイザリの閲覧」を参照してください。

ユーザーは、REST API を使ってリポジトリの依存関係を送信することで、リポジトリの依存関係グラフを設定できます。 依存関係グラフは、Dependabot アラートと Dependabot セキュリティ更新を強化します。 詳しくは、「Dependency Submission API を使用する」をご覧ください。

GitHub Actions は、ログ、成果物、キャッシュのストレージ プロバイダーとして Google Cloud Storage をサポートしています。 詳細については、「Google Cloud Storage で GitHub Actions を有効にする」を参照してください。

依存関係キャッシュを使ってワークフローを高速化する GitHub Actions ユーザーは、GitHub CLI を使って、リポジトリに関する GitHub Actions キャッシュを管理できるようになりました。 GitHub CLI を使ってキャッシュを管理するには、gh-actions-cache 拡張機能をインストールします。 詳細については、gh-actions-cache のドキュメントを参照してください。

GitHub Actions でのワークフローの再実行では、特権評価のためにワークフローを最初にトリガーしたアクターが使われます。 再実行をトリガーしたアクターは、引き続き UI に表示され、github コンテキストの triggering_actor フィールドを介してワークフローでアクセスできます。 詳細については、「ワークフローとジョブの再実行」と「コンテキスト」を参照してください。

ユーザーは、マトリックスまたは他の再利用可能なワークフローから、再利用可能なワークフローを呼び出すことができます。 詳細については、「ワークフローの再利用」を参照してください。

GitHub Actions で成果物のクエリを実行すると、REST API はその成果物を生成した実行とブランチに関する情報を返します。 詳細については、REST API のドキュメントの「GitHub Actions 成果物」を参照してください。

セキュリティ保護された大規模なクラウドのデプロイをサポートするため、組織所有者とリポジトリ管理者は、OpenID Connect REST API を使って次のタスクを行うことができます。 詳細については、REST API のドキュメントの「GitHub Actions OIDC」を参照してください

• subject 要求形式をカスタマイズすることで、クラウド デプロイ ワークフロー全体で OpenID Connect の標準構成を有効にします。
• issuer URL に企業のスラッグを追加することで、OpenID Connect のデプロイに対する追加のコンプライアンスとセキュリティを実現します。
• repository_id や repo_visibility などの追加の OpenID Connect トークン要求を使って、高度な OpenID Connect ポリシーを構成します。

詳しくは、「OpenID Connect を使用したセキュリティ強化について」をご覧ください。

依存関係キャッシュを使ってワークフローを高速化する GitHub Actions のユーザーは、GitHub Actions Cache REST API を使って次のタスクを実行できるようになりました。

• リポジトリ内のすべてのキャッシュの一覧を表示し、メタデータで並べ替えます。
• 破損した、または古いキャッシュ エントリを削除します。 詳細については、「依存関係をキャッシュしてワークフローのスピードを上げる」と、REST API のドキュメントの「GitHub Actions キャッシュ」を参照してください。

エフェメラルではないセルフホステッド GitHub Actions ランナーが 14 日より長く GitHub Enterprise Server インスタンスと通信しない場合、インスタンスはランナーを自動的に削除します。 エフェメラルであるセルフホステッド ランナーが 1 日より長くインスタンスと通信しない場合、インスタンスはランナーを自動的に削除します。 以前の GitHub Enterprise Server は、30 日後にランナーを削除しました。 詳細については、セルフホステッド ランナーに関する記述をご覧ください。

GitHub Actions は、M1 や M2 チップなどの Apple シリコンのランナー サポートを使って、macOS ARM64 ランタイムでセルフホステッド macOS ワークフローを実行できます。 詳細については、「ワークフローでのセルフホステッド ランナーの使用」を参照してください。

ユーザーは、発行ソースを構成することなく、GitHub Actions を使ってリポジトリから GitHub Pages サイトを直接デプロイできます。 GitHub Actions を使うと、作成フレームワークとバージョンを制御できるだけでなく、デプロイ ゲートなどの機能を使って発行プロセスをより細かく制御できます。 詳細については、「ご利用の GitHub Pages サイトに合わせた公開元の構成」を参照してください。

エンタープライズ所有者は、ユーザーが自分のユーザー アカウントによって所有されるリポジトリを作成するのを禁止できます。 詳細については、「Enterprise でリポジトリ管理ポリシーを適用する」を参照してください。

エンタープライズ所有者は、ユーザーがリポジトリをフォークできる場所を制御できます。 フォークを、組織の事前設定された組み合わせ、親リポジトリと同じ組織、ユーザー アカウント、またはすべての場所に制限できます。 詳細については、「Enterprise でリポジトリ管理ポリシーを適用する」を参照してください。

リポジトリ管理者は、1 回のプッシュで更新できるブランチとタグの数を制限することで、破壊的なプッシュをブロックできます。 既定では、1 回のプッシュで更新できるブランチとタグの数に制限はありません。 詳細については、「リポジトリのプッシュ ポリシーを管理する」を参照してください。

ユーザーは、pull request をスカッシュマージするときに、既定のコミット メッセージをさらにカスタマイズできます。 詳しくは、「pull request のコミット マージを構成する」と「pull request にコミットの squash を設定する」をご覧ください。

ユーザーは、リポジトリの [ブランチ] ページで [新しいブランチ] をクリックすることで、ブランチを作成できます。 詳細については、「リポジトリ内でブランチを作成および削除する」を参照してください。

ユーザーがファイルの名前を変更したり、新しいディレクトリにファイルを移動したりするとき、ファイルの内容の少なくとも半分が同じ場合は、git log --follow と同様に、コミット履歴ではファイルの名前が変更されたものとして示されます。 詳細については、GitHub ブログを参照してください。 [更新日: 2023 年 2 月 10 日]

フォークの作成と管理が改善されました。

• リポジトリをフォークするとき、ユーザーはリポジトリの既定のブランチのみをフォークに含めることを選択できます。
• ユーザーは、リポジトリの [フォーク] ボタンを使って、リポジトリの既存のフォークを確認できます。
• [アップストリームのフェッチ] ボタンの名前が [フォークの同期] に変更され、ボタンの動作がわかりやすくなりました。 同期によって競合が発生する場合、親リポジトリへの変更の反映、変更の破棄、または競合の解決をユーザーに求めるメッセージが Web UI に表示されます。
• ある組織で作業しているユーザーが、異なる組織またはユーザー アカウントにリポジトリをフォークしたくない状況に対処するため、ユーザーはリポジトリを親リポジトリと同じ組織にフォークできます。
• ユーザーは内部リポジトリを別の組織にフォークすることができ、フォークは内部の可視性を維持します。 内部リポジトリをフォークするとき、ユーザーはフォークを所有する組織を選択できます。

詳細については、「リポジトリのフォーク」を参照してください。

リポジトリ管理者は、 [Restrict pushes that create matching branches] (一致するブランチを作成するプッシュを制限する) ブランチ保護ルールを使って、構成されている名前パターンに一致するブランチの作成をブロックできます。 たとえば、リポジトリの既定のブランチが master から main に変わる場合、リポジトリ管理者はそれ以降の master ブランチの作成またはプッシュをすべて禁止できます。 詳細については、「保護されたブランチについて」と「ブランチ保護ルールを管理する」を参照してください。

ユーザーは、geoJSON、topoJSON、STL のダイアグラムを使ってファイルを作成し、Web インターフェイスでダイアグラムをレンダリングできます。 詳細については、「非コード ファイルでの作業」を参照してください。

ユーザーは、英数字または数字の識別子を使って、自動リンク参照を作成できます。 詳細については、外部リソースの自動リンクを参照する自動リンクの構成に関する記事を参照してください。

ユーザーは、.gitattributes ファイル内の linguist 属性を使って、vendor/ や build/ などのファイル ファインダーでの除外をカスタマイズできます。 詳細については、「GitHub でファイルを検索する」と「変更したファイルの GitHub での表示方法をカスタマイズする」を参照してください。

ユーザーは、ツリー ビューを使って、個々のコミットで変更されたファイルを参照できます。 詳細については、「コミットについて」を参照してください。

ユーザーは、issue のサイドバーの [開発] セクションから、既存のブランチまたは pull request を issue に手動でリンクできます。 詳細については、「pull request を Issue にリンクする」を参照してください。

ユーザーは、Markdown を記述するときに Mermaid 構文を使用できます。これにより、Markdown をレンダリングするとダイアグラムが表示されます。 詳細については、「Creating diagrams (ダイアグラムの作成)」を参照してください。

ユーザーは、既存の区切り記号に加えて math 構文を使い、フェンスされたコード ブロックを使って数式を記述できます。 $$ は、この方法では必要ありません。 詳しくは、「数式の記述」をご覧ください。

• 注: この機能は、GitHub Enterprise Server 3.7 では使用できません。 この機能は、今後のリリースで提供する予定です。 [更新日: 2022 年 11 月 16 日]

ユーザーは、geojson または topojson 構文でフェンスされたコード ブロックを使って Markdown でマップを直接レンダリングでき、stl 構文を使って STL 3D レンダリングを埋め込むことができます。 詳細については、「Creating diagrams (ダイアグラムの作成)」を参照してください。

Markdown では、ユーザーは LaTeX スタイルの構文を記述することで、$ 区切り記号を使ってインラインに、または $$ 区切り記号を使ってブロック内に、数式をレンダリングできます。 詳しくは、「数式の記述」をご覧ください。

安定性を高めるため、GeoJSON、Jupyter Notebook、PDF、PSD、SVG、SolidWorks、その他のバイナリ形式をレンダリングするためのサービスが置き換えられました。

インスタンスに対して TLS とサブドメインの分離が構成されていて、証明書がワイルドカード証明書でない場合は、これらのサービスに対する追加のサブドメイン (notebooks.HOSTNAME と viewscreen.HOSTNAME) を含む新しい証明書を生成する必要があります。 詳細については、「サブドメイン分離の有効化」を参照してください。 [更新日: 2022 年 12 月 2 日]

シークレット スキャンでは、[シークレットの後] フィールドで終了区切り記号として .* を使うカスタム パターンがサポートされなくなりました。このパターン構文では、スキャンの問題と不整合が発生します。

新しいリリースを作成するとき、ユーザーは、macOS では Ctrl + Enter キー、Windows または Linux では Ctrl + Enter キーを使って、フォームを送信できるようになりました。

リポジトリの [Wiki] タブは、Wiki が存在する場合にのみ表示されます。 以前は、このタブは常に表示されました。

レンダリングされた Wiki には、数式と Mermaid ダイアグラムが表示されます。

ユーザー、組織、エンタープライズの監査ログの検索フィールドのサイズが大きくなりました。

ランナー グループ内のセルフホステッド ランナーの最大数は 10,000 に制限されています。 以前は、制限はありませんでした。 [更新日: 2023 年 5 月 24 日]

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

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

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

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

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

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

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

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

構成の実行の検証フェーズ中に、Notebook と Viewscreen のサービスで No such object エラーが発生する可能性があります。 サービスが引き続き正しく起動するため、このエラーは無視することができます。

場合によっては、GitHub Enterprise Server 3.7.0 にアップグレードした後、ユーザーが SSH または HTTPS 経由で git 操作を開始するときに、Internal Server Error または 500 エラーが発生することがあります。 例:

git push origin master
Total 0 (delta 0), reused 0 (delta 0)
remote: Internal Server Error
To ghes.hostname.com:User/repo.git
! [remote rejected]       master -> master (Internal Server Error)

これらが発生した場合は、サポート バンドルで GitHub Enterprise サポートにお問い合わせください。 現時点での既知の一時的な回避策としては、次のコマンドを使って github-gitauth サービスを再起動します。

nomad stop github-gitauth
nomad run /etc/nomad-jobs/github/gitauth.hcl
nomad status github-gitauth

現在、今後のホット パッチのために永続的な修正を調査しています (更新日: 2022 年 11 月 24 日)。

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

TLS とサブドメイン分離が有効になっているインスタンスでドメイン設定を検証する場合、管理コンソールには、GitHub Enterprise Server 3.7 の 2 つの新しいサブドメイン http(s)://notebooks.HOSTNAME と http(s)://viewscreen.HOSTNAME がドメインのリストに表示されません。 [更新日: 2023 年 1 月 12 日]

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

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

高可用性構成のインスタンスでは、サイト管理者はインスタンスがメンテナンス モードになっている間のみ ghe-repl-start と ghe-repl-stop コマンドを実行する必要があります。 詳細については、「メンテナンスモードの有効化とスケジューリング」および「High Availability設定について」を参照してください。 [更新日: 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]