ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。
2.22

3.0 Release notes

3.1

Enterprise Server 3.0.7

Download

May 13, 2021

📣 This is not the latest release of Enterprise Server. Please use the latest release for the latest security, performance, and bug fixes.

  • HIGH: A UI misrepresentation vulnerability was identified in GitHub Enterprise Server that allowed more permissions to be granted during a GitHub App's user-authorization web flow than was displayed to the user during approval. To exploit this vulnerability, an attacker would need to create a GitHub App on the instance and have a user authorize the application through the web authentication flow. All permissions being granted would properly be shown during the first authorization, but in certain circumstances, if the user revisits the authorization flow after the GitHub App has configured additional user-level permissions, those additional permissions may not be shown, leading to more permissions being granted than the user potentially intended. This vulnerability affected GitHub Enterprise Server 3.0.x prior to 3.0.7 and 2.22.x prior to 2.22.13. It was fixed in versions 3.0.7 and 2.22.13. This vulnerability has been assigned CVE-2021-22866 and was reported via the GitHub Bug Bounty Program.

  • Packages have been updated to the latest security versions.

  • Quotes included in Actions or Packages storage configuration could cause errors.

  • Custom pre-receive hooks could fail due to too restrictive file size or number of open file limits.

  • Orchestrator auto failover could be enabled during the phase of config apply.

  • Users with maintainer permissions to a repository were shown an e-mail verification warning instead of a successful page build on the repository Pages settings page.

  • The code owner of a wildcard rule would be incorrectly added to the list of owners for the code owners badge even if a later rule took precedence for that path.

  • OpenAPI documentation referred to an invalid header.

  • When creating or editing a pre-receive hook, a race condition in the user interface meant that after selecting a repository, files within the repository were sometimes not populated in files dropdown.

  • Added logging for config change on HAProxy reload.

  • Added logging for repository creation.

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

  • Custom firewall rules are not maintained during an upgrade.

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

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

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

Enterprise Server 3.0.6

Download

April 28, 2021

📣 This is not the latest patch release of this release series, and this is not the latest release of Enterprise Server. Please use the latest release for the latest security, performance, and bug fixes.

  • Packages have been updated to the latest security versions.

  • During upgrades, the process would pause indefinitely after cleanup nomad job.

  • Failing ghe-cluster-failover with the error message Trilogy::Error: trilogy_connect.

  • ghe-cluster-status-mysql showed warnings about failovers as errors.

  • Setup script running on MySQL replication may have caused unnecessary database reseeding during database failover.

  • Upgrades did not include the latest version of Actions runner properly installed.

  • github-env configuration could result in zombie processes.

  • config-apply could take longer than necessary due to rake db:migrate being called unnecessarily.

  • Orchestrator could have failed over to a MySQL replica which was not replicating from primary during seeding phase when primary could not be connected.

  • Organizations or projects with errors blocked migration and could not be excluded.

  • The Create Repository button was disabled for users who belonged to more than 50 organizations.

  • Deleting a branch would temporarily flash an error message indicating something went wrong when the deletion was successful.

  • The rms-packages index was shown in the site admin dashboard.

  • Organization owner was unable to create internal repository due to the correct visibility options not being displayed on the form.

  • The repository actions tab rendered a 500 in cases where the actions starter workflows were misconfigured.

  • Customers with more than three storage hosts were unable to restore to their disaster-recovery cluster due to the fullest disks being selected instead of empty nodes.

  • Code Scanning backend services did not start up reliably after applying hotpatches.

  • Preflight checks allow all AWS instance types by default.

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

  • Custom firewall rules are not maintained during an upgrade.

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

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

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

Enterprise Server 3.0.5

Download

April 14, 2021

📣 This is not the latest patch release of this release series, and this is not the latest release of Enterprise Server. Please use the latest release for the latest security, performance, and bug fixes.

The minimum infrastructure requirements have increased for GitHub Enterprise Server 3.0+. For more information, see "About minimum requirements for GitHub Enterprise Server 3.0 and later."

  • Packages have been updated to the latest security versions.

  • Some logs were not included in the log forwarding configuration.

  • A warning message jq: error (at <stdin>:0): Cannot index number with string "settings" could occur during replica promotion.

  • Continuously restoring backups to a cluster could fail due to MySQL replicas failing to connect to the primary.

  • Pages were not getting published when using custom CA certificate.

  • Packages related subdomains were not showing up in the "Test domain settings" prompt for subdomain isolation.

  • The X-GitHub-Enterprise-Host header sent with webhooks included a random string, rather than the hostname of the GitHub Enterprise Server instance that sent the HTTP POST payload.

  • Upgrading from 2.22.x to 3.0.x would fail if GitHub Actions had previously been enabled, but disabled before the upgrade.

  • Visiting the /settings/emails page would store state that could cause improper redirects when logging out and logging back in.

  • GitHub integration apps were not able to notify teams when mentioned directly via an at-mention in an issue comment.

  • reStructuredText (RST) rendering in the web UI would fail and instead displayed raw RST markup text.

  • Email notifications for Secret Scanning alerts were not sent to authorized users when the Dependency Graph was not fully enabled.

  • When ghe-migrator encountered import errors, it would sometimes abort the entire process, and the logs did not include enough context.

  • Jupyter notebooks with non-ASCII characters could fail to render.

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

  • Custom firewall rules are not maintained during an upgrade.

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

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

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

  • When deleting a branch after merging a pull request, an error message appears although the branch deletion succeeds.

Enterprise Server 3.0.4

Download

April 01, 2021

📣 This is not the latest patch release of this release series, and this is not the latest release of Enterprise Server. Please use the latest release for the latest security, performance, and bug fixes.

GitHub Enterprise Server 3.0以降では最小のインフラストラクチャの要件が増加されました。詳しい情報については「GitHub Enterprise Server 3.0以降に対する最小要件について」を参照してください。

  • 高: GitHub AppのWeb認証フローから生成されたアクセストークンに対し、適切な権限が許可されていなくてもREST APIを通じてプライベートなリポジトリのメタデータを読めるようにしてしまう、不適切なアクセス制御の脆弱性がGitHub Enterprise Serverで特定されました。この脆弱性を利用するには、攻撃者はそのインスタンス上でGitHub Appを作成し、Web認証フローを通じてそのアプリケーションを認証するユーザが必要です。返されるプライベートリポジトリのメタデータは、そのトークンが特定するユーザが所有するリポジトリに限定されます。この脆弱性は3.0.4以前のすべてのバージョンのGitHub Enterprise Serverに影響し、3.0.4、2.22.10、2.21.18で修正されました。この脆弱性にはCVE-2021-22865が割り当てられ、 GitHub Bug Bounty Programを通じて報告されました。

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

  • メンテナンスモードが有効になっている場合に、一部のサービスは実行中であることが期待され、リストに表示されるべきではないにも関わらず、"active processes"としてリストされ続けました。

  • GitHub Actionsを有効化して2.22.xから3.0.xへアップグレードした後、セルフホストランナーのバージョンが更新されず、セルフホストの更新が行われませんでした。

  • 古いGitHub Pagesのビルドがクリーンアップされず、ディスク使用量の増大につながりました。

  • アクティブなレプリカ上でmemcachedが動作していませんでした。

  • GitHub Actionsが有効化されている場合に、ファイル権限の更新時に更新が失敗しました。

  • GitHub Enterprise 11.10.x以前で設定されたタイムゾーンが一部のサービスで利用されず、デフォルトのUTC時間になっていました。

  • ログローテーションの一部としてサービスが新しいログファイルに移行せず、ディスクの使用量が増大しました。

  • コマンドラインユーティリティのghe-saml-mapping-csvが警告メッセージを生成しました。

  • インターナルリポジトリの検索結果上のラベルが"Internal"ではなく"Private"と表示されました。

  • 新しくセットアップされたユーザを持たないGitHub Enterprise Serverで、攻撃者が最初の管理ユーザを作成できました。

  • カスタムのファイアウォールのルールは、アップグレードの際に維持されません。

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

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

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

  • ノートブックに非ASCIIのUTF-8文字が含まれている場合、Web UI中でのJupyter Notebookのレンダリングが失敗することがあります。

  • Web UIでのreStructuredText (RST) のレンダリングが失敗し、代わりにRSTのマークアップテキストがそのまま表示されることがあります。

  • When deleting a branch after merging a pull request, an error message appears although the branch deletion succeeds.

Enterprise Server 3.0.3

Download

March 23, 2021

📣 This is not the latest patch release of this release series, and this is not the latest release of Enterprise Server. Please use the latest release for the latest security, performance, and bug fixes.

複数のお客様に影響する重大なバグのため、ダウンロードは無効になりました。修正は次回のパッチで利用可能になります。

  • 高: GitHubPagesのサイトをビルドする際に利用される可能性があるリモートコード実行の脆弱性が、GitHub Enterprise Serverで特定されました。GitHub Pagesが使用するユーザが制御する設定オプションが十分に厳密ではなく、環境変数を上書きできてしまい、GitHub Enterprise Serverインスタンス上でコマンドを実行できてしまいます。この脆弱性を利用するには、攻撃者はGitHub Enterprise Serverインスタンス上でGitHub Pagesのサイトを作成してビルドする権限を持っていなければなりません。この脆弱性は3.0.3以前のすべてのバージョンのGitHub Enterprise Serverに影響し、3.0.3、2.22.9、2.21.17で修正されました。この脆弱性はGitHub Bug Bountyプログラムを通じて報告され、CVE-2021-22864が割り当てられました。

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

  • ghe-cluster-config-initを実行すると、クラスタが動作しなくなることがありました。

  • GUI中でのマージコンフリクトの解決が、リポジトリでカスタムのpre-receiveフックが設定されている場合に失敗します。

  • launch-deployer及びlaunch-receiverがDEBUGレベルでロギングされ、不要な情報でログを埋めてしまいました。

  • システムがHAProxyのPIDを見失うことがありました。

  • アクションがS3ストレージを使うように設定されていると、アクションのログのロードに失敗することがあります。

  • 成功したフェイルオーバーの後、mysql-failoverの警告が無期限に表示されました。

  • ghe-cluster-config-initの実行でバックグラウンドジョブの終了コードが完全に考慮されておらず、プリフライトチェックが不適切に処理されることにつながっていました。

  • GitHub Actionsを有効化する際に、初期化が何の反応もなしに失敗することがありました。

  • 脆弱性アラートが有効になっていると、3.0シリーズへのアップグレードに失敗します。

  • Codespacesに関連するジョブがキューに追加され、未処理のジョブが蓄積されることになりました。

  • consulとnormadのbootstrap_expectに相対的な値を使用することによって、クラスタは少数のノードがダウンしている場合でもブートストラップできます。

  • ログが、時間に加えてサイズに基づいてローテートされます。

  • ghe-cluster-statusコマンドにkafka-liteを追加しました。

  • 新しくセットアップされたユーザを持たないGitHub Enterprise Serverで、攻撃者が最初の管理ユーザを作成できました。

  • カスタムのファイアウォールのルールは、アップグレードの際に維持されません。

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

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

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

  • メンテナンスモードが有効化されているとき、サービスの中に引き続き"active processes"としてリストされるものがあります。特定されたサービスは、メンテナンスモード中にも実行されることが期待されるものです。この問題が生じており、不確実な場合はGitHub Enterprise SupportもしくはGitHub Premium Supportにお問い合わせください。

  • ノートブックに非ASCIIのUTF-8文字が含まれている場合、Web UI中でのJupyter Notebookのレンダリングが失敗することがあります。

  • Web UIでのreStructuredText (RST) のレンダリングが失敗し、代わりにRSTのマークアップテキストがそのまま表示されることがあります。

  • Pagesの古いビルドがクリーンアップされず、ユーザディスク(/data/user/)を使い切ってしまうことがあります。

  • ログのローテーションが新しいログファイルへの移行をサービスに通知するのに失敗し、古いログファイルが使われ続け、最終的にルートディスクの領域が枯渇してしまうことがあります。 この問題を緩和し、回避するために、以下のコマンドを管理シェル (SSH)で実行するか、 GitHub Enterprise SupportあるいはGitHub Premium Supportに連絡して支援を求めてください。

    printf "PATH=/usr/local/sbin:/usr/local/bin:/usr/local/share/enterprise:/usr/sbin:/usr/bin:/sbin:/bin\n29,59 * * * * root /usr/sbin/logrotate /etc/logrotate.conf\n" | sudo sponge /etc/cron.d/logrotate
    sudo /usr/sbin/logrotate -f /etc/logrotate.conf
    
  • Log rotation may fail to signal services to transition to new log files, leading to older log files continuing to be used, and eventual root disk space exhaustion. To remedy and/or prevent this issue, run the following commands in the administrative shell (SSH), or contact GitHub Enterprise Support or GitHub Premium Support for assistance:

    printf "PATH=/usr/local/sbin:/usr/local/bin:/usr/local/share/enterprise:/usr/sbin:/usr/bin:/sbin:/bin\n29,59 * * * * root /usr/sbin/logrotate /etc/logrotate.conf\n" | sudo sponge /etc/cron.d/logrotate
    sudo /usr/sbin/logrotate -f /etc/logrotate.conf
    

Enterprise Server 3.0.2

Download

March 16, 2021

📣 This is not the latest patch release of this release series, and this is not the latest release of Enterprise Server. Please use the latest release for the latest security, performance, and bug fixes.

GitHub Enterprise Server 3.0以降では最小のインフラストラクチャの要件が増加されました。詳しい情報については「GitHub Enterprise Server 3.0以降に対する最小要件について」を参照してください。

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

  • バックアップ中に、パージ可能なストレージオブジェクトをクリーンアップしようとしたときに、"Warning: One or more storage objects were not found on the source appliance."というエラーが生じました。

  • 依存関係グラフがJavaScriptのyarn.lockマニフェストファイルのパースに失敗し、ログにHTTP 500エラーが残りました。

  • GitHub Actionsの無効化に失敗することがあります。

  • カスタムのpre-receiveフックに/tmpへの書き込みが許されず、正しく実行できないスクリプトがあります。

  • Systemdのジャーナルログが複数の場所で複製されました。

  • GitHub Enterprise 11.10.x以前で設定されたタイムゾーンが、3.0へのアップグレードの後でUTC時間にリセットされ、インスタンスによってはタイムスタンプがずれることがありました。

  • リポジトリのPackagesサイドバーの"Publish your first package"をクリックすると、空のページが表示されます。

  • サイト管理者がプライベートリポジトリから参照されているIssueを見ようとすると、500エラーページが返されることがありました。

  • GitHub Packagesを無効化した後、HTTP 500エラーレスポンスを返すOrganizationのページがあります。

  • GitHub Enterprise Serverから、リポジトリのファイルがないリポジトリアーカイブをインポートすると、エラーで失敗します。

  • リポジトリのデプロイキーが、LFSオブジェクトを含むリポジトリで利用できませんでした。

  • リポジトリのPackagesサイドバー内で、Dockerのアイコンが灰色になっており、ツールチップが"This service is deprecated"と表示しました。

  • application/x-www-form-urlencodedというコンテントタイプで設定されたwebhookは、POSTのリクエストボディ中のクエリパラメータを受信しませんでした。

  • ユーザが、すべてのチェックボックスをチェックすることなく必須のメッセージを閉じることができました。

  • 2.22.Xインスタンスからアップグレードした後、webインターフェースのアセットが欠けて、ページが正しく描画されないことがありました。

  • ghe-config-applyを実行すると、'job' stanza not foundによってFailure waiting for nomad jobs to applyでタイムアウトになることがありました。

  • 新しくセットアップされたユーザを持たないGitHub Enterprise Serverで、攻撃者が最初の管理ユーザを作成できました。

  • カスタムのファイアウォールのルールは、アップグレードの際に維持されません。

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

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

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

  • メンテナンスモードが有効化されているとき、サービスの中に引き続き"active processes"としてリストされるものがあります。特定されたサービスは、メンテナンスモード中にも実行されることが期待されるものです。この問題が生じており、不確実な場合はGitHub Enterprise SupportもしくはGitHub Premium Supportにお問い合わせください。

  • ノートブックに非ASCIIのUTF-8文字が含まれている場合、Web UI中でのJupyter Notebookのレンダリングが失敗することがあります。

  • Web UIでのreStructuredText (RST) のレンダリングが失敗し、代わりにRSTのマークアップテキストがそのまま表示されることがあります。

  • Pagesの古いビルドがクリーンアップされず、ユーザディスク(/data/user/)を使い切ってしまうことがあります。

  • ユーザは、アバターのようなアセットがロードされないことや、コードのプッシュ/プルの失敗を体験するかもしれません。これは、haproxy-cluster-proxyサービス内のPIDミスマッチによって生じることがあります。影響されたインスタンスがあるかは、以下のようにして判断します。

    単一インスタンス

    1. 以下を管理シェル (SSH)で実行してください:

      if [ $(cat /var/run/haproxy-cluster-proxy.pid) -ne $(systemctl show --property MainPID --value haproxy-cluster-proxy) ]; then echo 'Main PID of haproxy-cluster-proxy does not match /var/run/haproxy-cluster-proxy.pid'; fi
      
    2. ミスマッチがあると表示されたら、インスタンスを再起動してください。

    クラスタもしくはHigh Availability構成

    1. 以下を管理シェル (SSH)で実行してください:

      ghe-cluster-each -- 'if [ $(cat /var/run/haproxy-cluster-proxy.pid) -ne $(systemctl show --property MainPID --value haproxy-cluster-proxy) ]; then echo 'Main PID of haproxy-cluster-proxy does not match /var/run/haproxy-cluster-proxy.pid'; fi'
      
    2. 1つ以上のノードが影響されていると表示されたら、影響されているノードを再起動してください。

  • Users may experience assets such as avatars not loading, or a failure to push/pull code. This may be caused by a PID mismatch in the haproxy-cluster-proxy service. To determine if you have an affected instance:

    Single instance

    1. Run this in the administrative shell (SSH):

      if [ $(cat /var/run/haproxy-cluster-proxy.pid) -ne $(systemctl show --property MainPID --value haproxy-cluster-proxy) ]; then echo 'Main PID of haproxy-cluster-proxy does not match /var/run/haproxy-cluster-proxy.pid'; fi
      
    2. If it shows that there is a mismatch, reboot the instance.

    Cluster or High Availability configuration

    1. Run this in the administrative shell (SSH):

      ghe-cluster-each -- 'if [ $(cat /var/run/haproxy-cluster-proxy.pid) -ne $(systemctl show --property MainPID --value haproxy-cluster-proxy) ]; then echo 'Main PID of haproxy-cluster-proxy does not match /var/run/haproxy-cluster-proxy.pid'; fi'
      
    2. If it shows one or more nodes are affected, reboot the affected nodes.

Enterprise Server 3.0.1

Download

March 02, 2021

📣 This is not the latest patch release of this release series, and this is not the latest release of Enterprise Server. Please use the latest release for the latest security, performance, and bug fixes.

GitHub Enterprise Server 3.0以降では最小のインフラストラクチャの要件が増加されました。詳しい情報については「GitHub Enterprise Server 3.0以降に対する最小要件について」を参照してください。

  • 高: 特別な細工が行われたPull RequestやREST APIのリクエストを通じて、認可されていないリポジトリへの書き込みアクセスを、インスタンスの認証されたユーザが取得できてしまう、不適切なアクセス制御の脆弱性がGitHub Enterprise Serverで特定されました。攻撃者はターゲットのリポジトリをフォークできなければなりませんが、これはOrganizationが所有しているプライベートリポジトリではデフォルトで無効化されている設定です。必須のPull Requestレビューやステータスチェックといったブランチ保護で、さらなるレビューや検証なしに未認可のコミットがマージされることは避けられます。この脆弱性にはCVE-2021-22861が割り当てられました。この問題は、GitHub Bug Bounty Programを通じて報告されました。

  • 高: 適切な認可なしに、Pull Requestのメンテナのコラボレーション権限を修正できる、不適切なアクセス制御の脆弱性がGitHub Enterprise Serverで特定されました。この脆弱性を突くことで、攻撃者は自分がメンテナになっているリポジトリでオープンされたPull Requestのheadブランチへのアクセスを得ることができます。Organizationが所有するプライベートリポジトリではフォークがデフォルトで無効になっており、この脆弱性を避けることができます。加えて、必須のPull Requestレビューやステータスチェックといったブランチ保護で、さらなるレビューや検証なしに未認可のコミットがマージされることは避けられます。この脆弱性にはCVE-2021-22863が割り当てられました。この問題は、GitHub Bug Bounty Programを通じて報告されました。

  • 高: リポジトリをフォークできる認証されたユーザが、フォークの親リポジトリのActionsのシークレットを開示できてしまう、不適切なアクセス制御の脆弱性がGitHub Enterprise Serverで特定されました。この脆弱性が存在したのは、任意のSHAもしくはフォークリポジトリ外の他のPull Requestの時点まで、Pull Requestのベース参照を更新できる欠陥のためです。PR内のこの正しくない参照を確立することによって、フォークからワークフローに送信されるActionsのシークレットを限定する制限がバイパスされることがありました。この脆弱性は、GitHub Enterprise Serverのバージョン3.0.0、3.0.0.rc2、3.0.0.rc1に影響するもので、CVE-2021-22862が割り当てられました。この脆弱性はGitHub Bug Bountyプログラムを通じて報告されました。

  • 中: GitHub PagesのビルドからのGitHubトークンがログに残ることがあります。

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

  • ロードバランサーのヘルスチェックによって、babeldのログがPROXYプロトコルに関するエラーで埋め尽くされてしまうことがあります。

  • HTTPヘッダが、アーカイブに対する304ステータスのような特定のレスポンスにおいてHTTP RFC標準に準拠していませんでした。

  • 依存関係グラフの機能が有効化されたPythonのリポジトリをホストするインスタンスにおいて、ルートディスクがエラーログで埋め尽くされてしまい、インスタンスが応答しなくなることがありました。

  • GitHub Enterprise Backup Utilitiesがスナップショットを取る際に、情報提供のメッセージが意図せずエラーとして記録され、そのためにcronジョブによってスケジュールされたstderrへの出力を待ち受けているバックアップの際に、不要なメールが送信されてしまいます。

  • VMWare ESX 6.7において、初期の設定がホストのキーを生成する際にハングし、そのインスタンスがSSHでアクセスできなくなってしまうことがありました。

  • GitHub Actionsが有効化されていると、管理コンソールでメンテナンスモードの無効化に失敗します。

  • パッケージ作成の設定がOrganizationメンバーの設定ページに表示されますが、この機能はまだ利用できません。

  • Security & AnalysisページでSecret Scanningを有効化する際に、ダイアログが誤ってプライベートリポジトリに触れます。

  • Wikiページを編集する際に、保存ボタンをクリックすると500エラーが返されることがあります。

  • サブジェクトの別名に複数の名前がある証明書を使ってS/MIME署名されたコミットで、誤ってコミットバッジに"Unverified"と表示されます。

  • LDAP認証を設定されたインスタンス上でGitの操作を実行したユーザに500エラーが返されました。

  • サスペンドされたユーザがTeamに追加されると、メールが送信されます。

  • リポジトリが大量のマニフェストを持っていると、You have reached the maximum number of allowed manifest files (20) for this repositoryというエラーがInsights -> Dependency graphタブに表示されます。詳しい情報については可視化の制限を参照してください。

  • 所有するリポジトリでActionsが有効化されていなくても、ユーザにCode Scanning CodeQL Actionをセットアップするオプションが表示されてしまうのを修正しました。

  • Enterpriseアカウント設定にある"Prevent repository admins from changing anonymous Git read access"チェックボックスが、正常に有効化または無効化できませんでした。

  • 須のメッセージを表示するために使われるモーダルに垂直スクロールバーが含まれず、長いメッセージをすべて見ることができませんでした。

  • ハードリブートやアプリケーションのクラッシュ後に、Redisの起動に失敗することがあります。

  • 依存関係グラフがPythonのsetup.pyマニフェストファイルのパースに失敗し、HTTP 500エラーがログに残されます。これが重複されるロギングの問題と組み合わさると、ルートボリュームの使用率が増大します。

  • 複数のユーザが同じアーカイブを並行してダウンロードするリクエストが処理され、パフォーマンスが向上します。

  • 新しくセットアップされたユーザを持たないGitHub Enterprise Serverで、攻撃者が最初の管理ユーザを作成できました。

  • カスタムのファイアウォールのルールは、アップグレードの際に維持されません。

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

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

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

  • メンテナンスモードが有効化されているとき、サービスの中に引き続き"active processes"としてリストされるものがあります。特定されたサービスは、メンテナンスモード中にも実行されることが期待されるものです。この問題が生じており、不確実な場合はGitHub Enterprise SupportもしくはGitHub Premium Supportにお問い合わせください。

  • /var/log/messages/var/log/syslog/var/log/user.logへの重複したロギングによって、ルートボリュームの使用率が増大します。

  • ユーザが、すべてのチェックボックスをチェックすることなく必須のメッセージを閉じることができます。

  • pre-receiveフックスクリプトは一時ファイルを書くことができず、そのためにスクリプトの実行が失敗することがあります。pre-receiveフックを使うユーザは、ステージング環境でスクリプトが書き込みアクセス権を必要とするかを確認するためのテストをするべきです。

  • リポジトリのデプロイキーが、LFSオブジェクトを含むリポジトリで使用できません。

  • ノートブックに非ASCIIのUTF-8文字が含まれている場合、Web UI中でのJupyter Notebookのレンダリングが失敗することがあります。

  • Web UIでのreStructuredText (RST) のレンダリングが失敗し、代わりにRSTのマークアップテキストがそのまま表示されることがあります。

  • 依存関係グラフがJavaScriptのyarn.lockマニフェストファイルのパースに失敗し、ログにHTTP 500エラーが残ります。

  • 以前のGitHub Enterprise Serverのリリースからアップグレードされた、カスタムのタイムゾーンを持つインスタンスは、Web UIに不正確なタイムスタンプがあることがあります。

  • Pagesの古いビルドがクリーンアップされず、ユーザディスク(/data/user/)を使い切ってしまうことがあります。

  • ユーザは、アバターのようなアセットがロードされないことや、コードのプッシュ/プルの失敗を体験するかもしれません。これは、haproxy-cluster-proxyサービス内のPIDミスマッチによって生じることがあります。影響されたインスタンスがあるかは、以下のようにして判断します。

    単一インスタンス

    1. 以下を管理シェル (SSH)で実行してください:

      if [ $(cat /var/run/haproxy-cluster-proxy.pid) -ne $(systemctl show --property MainPID --value haproxy-cluster-proxy) ]; then echo 'Main PID of haproxy-cluster-proxy does not match /var/run/haproxy-cluster-proxy.pid'; fi
      
    2. ミスマッチがあると表示されたら、インスタンスを再起動してください。

    クラスタもしくはHigh Availability構成

    1. 以下を管理シェル (SSH)で実行してください:

      ghe-cluster-each -- 'if [ $(cat /var/run/haproxy-cluster-proxy.pid) -ne $(systemctl show --property MainPID --value haproxy-cluster-proxy) ]; then echo 'Main PID of haproxy-cluster-proxy does not match /var/run/haproxy-cluster-proxy.pid'; fi'
      
    2. 1つ以上のノードが影響されていると表示されたら、影響されているノードを再起動してください。

  • Users may experience assets such as avatars not loading, or a failure to push/pull code. This may be caused by a PID mismatch in the haproxy-cluster-proxy service. To determine if you have an affected instance:

    Single instance

    1. Run this in the administrative shell (SSH):

      if [ $(cat /var/run/haproxy-cluster-proxy.pid) -ne $(systemctl show --property MainPID --value haproxy-cluster-proxy) ]; then echo 'Main PID of haproxy-cluster-proxy does not match /var/run/haproxy-cluster-proxy.pid'; fi
      
    2. If it shows that there is a mismatch, reboot the instance.

    Cluster or High Availability configuration

    1. Run this in the administrative shell (SSH):

      ghe-cluster-each -- 'if [ $(cat /var/run/haproxy-cluster-proxy.pid) -ne $(systemctl show --property MainPID --value haproxy-cluster-proxy) ]; then echo 'Main PID of haproxy-cluster-proxy does not match /var/run/haproxy-cluster-proxy.pid'; fi'
      
    2. If it shows one or more nodes are affected, reboot the affected nodes.

Enterprise Server 3.0.0

Download

February 16, 2021

📣 This is not the latest patch release of this release series, and this is not the latest release of Enterprise Server. Please use the latest release for the latest security, performance, and bug fixes.

GitHub Enterprise Server 3.0以降では最小のインフラストラクチャの要件が増加されました。詳しい情報については「GitHub Enterprise Server 3.0以降に対する最小要件について」を参照してください。

  • 高: GitHub Pagesのサイトをビルドする際に利用される可能性があるリモートコード実行の脆弱性が、GitHub Enterprise Serverで特定されました。GitHub Pagesが使用する下位層のパーサーのユーザが制御する設定が十分に厳密ではなく、GitHub Enterprise Serverインスタンス上でコマンドを実行することができてしまいます。この脆弱性を利用するには、攻撃者はGitHub Enterprise Serverインスタンス上でGitHub Pagesのサイトを作成してビルドする権限を持っていなければなりません。この脆弱性にはCVE-2020-10519が割り当てられ、GitHub Bug Bounty Programを通じて報告されました。

  • GitHub Actions

    • GitHub ActionsはGitHub Enterprise Server 3.0以降で一般に利用可能になりました。GitHubからコードをビルド、テスト、デプロイしてください。コードレビューのサブミット、ブランチ管理、Issueのトリアージ作業を好きな方法で行ってください。

      このリリースには、GitHub Enterprise Server上のGitHub Actionsのベータからのいくつかの改善が含まれています。

      現時点で、クラスタ設定を使用するEnterpriseではGitHub Actionsはサポートされません。

  • GitHub Packages

    • GitHub Packages(https://github.com/features/packages)はパッケージホスティングサービスで、GitHub API、Actions、webhookとネイティブに統合されています。コード、継続的インテグレーション、デプロイメントのソリューションを含むエンドツーエンドのDevOpsワークフローを作成してください。

      サポートされるストレージのバックエンドにはAWS S3とMinIOが含まれ、将来のリリースでAzure blobもやってきます。現在のDockerサポートは、次のリリースの新しいGitHub Container Registryのベータで置き換えられることに注意してください。GitHub Packagesを有効にする前に、プラットフォームの最小要件の更新をレビューしてください。

      パッケージをNuGetに公開する際に、ユーザは認証トークンをファイルに書く代わりに--api-keyオプションを使って渡せるようになりました。詳しい情報についてはGitHub Packagesで使うためのdotnet CLIの設定を参照してください。

      現時点で、クラスタ構成を使用するEnterpriseではGitHub Packagesはサポートされていません。

  • GitHub Mobileベータ

    • GitHub for mobileベータを利用すれば、自分のデバイスから通知をトリアージし、IssueやPull Requestを管理できるようになります。モバイルには、GitHub.com上の1つのユーザアカウントと、GitHub Enterprise Server上の1つのユーザアカウントで同時にサインインできます。

      GitHub for mobileベータは、GitHub Enterprise Serverで利用できるようになりました。AndroidiOSのアプリケーションでサインインして、外出先で通知をトリアージし、IssueとPull Requestを管理してください。管理者は管理コンソールを使って、あるいはghe-config app.mobile.enabled falseを実行して、Enterpriseのモバイルサポートを無効化できます。

  • Advanced Security Secret Scanningベータ

    • Secret Scanningベータは、コミットされた認証情報をパブリック及びプライベートのリポジトリでスキャンし、シークレットを見つけ、それらがリポジトリにコミットされたときにシークレットの提供者あるいは管理者に通知します。

      GitHub Advanced Securityを利用する管理者は、GitHub Advanced Security Secret Scanningを有効化し、設定できます。GitHub Advanced Security Secret Scanningを有効化する前に、プラットフォームの最小要件の更新をレビューできます。

  • Advanced Security Code Scanning

    • GitHub Advanced Security code scanningは、GitHub Enterprise Serverで一般に利用可能になりました。Advanced Securityを購入したOrganizationは、この機能を使って静的解析のセキュリティテストをコードに対して行い、私たちのセマンティック解析エンジンであるCodeQLを使って脆弱性がプロダクションコードにまで及ぶことを回避できます。詳しい情報については「アプライアンス上でのcode scanningの設定」を参照してください。

  • 管理に関する変更

    • webhookイベントの配信システムは、スループットの向上、配信の高速化、遅延メッセージの減少のために再設計されました。GitHub Enterprise Server 3.0以降では、CPUとメモリの使用量も減少しています。

    • OrganizationとEnterpriseのオーナーは、TeamのメンバーがTeamのメンテナに昇格したり、メンテナから降格されたときに、新しいteam.promote_maintainer及びteam.demote_maintainer監査ログイベントを通じて監査ログで知ることができるようになりました。詳しい情報については「監査対象のアクション」を参照してください。

    • 既存のGitHub Pagesサイトを持つリポジトリ管理者は、以前のデフォルトブランチ名を容易に更新できるようになりました。

    • Actions、Packages、Advanced Securityのいずれかを有効にしてGitHub Enterprise Serverを動作させるには、追加のハードウェアリソースが必要になります。サポートされている各プラットフォームでの最小の必要リソースに関する詳しい情報については、「GitHub Enterprise Serverインスタンスのセットアップ」を参照してください。

    • 管理者は、すべてのユーザが受諾しなければならないメッセージを公開できるようになりました。これは、新しいユーザの参加と、Organization固有の情報やポリシーを示すための役に立ちます。

  • セキュリティの変更

    • Organizationのオーナーは、Organization内のリポジトリからのGitHub Pagesサイトの公開を無効化できるようになりました。OrganizationのGitHub Pagesを無効化すると、メンバーは新しいPagesのサイトを作成できなくなりますが、既存のサイトの公開は取り消されません。詳しい情報については「OrganizationでのGitHub Pagesサイトの公開の無効化」を参照してください。

    • アクティブなレプリカを有効化する前に、すべてのノードでデータセンターは明示的に定義されていなければなりません。

    • SSHフィンガープリントのすべての利用は、バージョン6.8以降のOpenSSHで使われているのと同様に、SHA256を使うように切り替えられました。これは、Webのインターフェースに適用されると共に、GraphQLのようにフィンガープリントを返すAPIにも適用されます。フィンガープリントは、OpenSSHのフォーマットに従います。

    • SHA-1及びSHA-256の署名ヘッダ(2つのヘッダ)は、webhook上で送信されます。

  • 開発者の変更

    • GitHub Enterprise Server 3.0以降で動作しているサービスの大部分はコンテナ上に置かれるようになり、内部的にGitHubが反復を早め、高品質なリリースを行えるようにしています。

    • webhookイベントの配信システムは、高いスループット、高速な配信、遅延するメッセージの減少のために、再設計されました。

  • API の変更

    • 管理者は、REST APIを通じてサイト全体のアナウンスのバナーを設定し、管理できるようになりました。詳しい情報については「GitHub Enterpriseの管理」のエンドポイントを参照してください。

    • 新しいAPIエンドポイントを使用して、ユーザからサーバーへのトークンを、特定のリポジトリをスコープとするユーザからサーバーへのトークンと交換できるようになりました。詳しい情報についてはGitHub REST APIドキュメンテーション中の「Apps」を参照してください。

  • デフォルトブランチの名称変更

    • Enterprise及びOrganizationの管理者は、新しいリポジトリのためのデフォルトブランチ名を設定できるようになりました。Enterprise管理者は、デフォルトブランチ名についての自分の選択をOrganization群全体に強制することも、個々のOrganizationが独自の選択をできるようにすることもできます。

      既存のリポジトリはこれらの設定に影響されず、デフォルトブランチ名は変更されません。

      Enterpriseレベルでデフォルトブランチの設定をしてオプトアウトしないかぎり、GHES 3.1では新しく作成されるリポジトリのデフォルトブランチはmainに設定されます。

      この変更は、デフォルトブランチの名前を変更したいプロジェクトやメンテナをサポートするためにGitHubが行っている多くの変更の中の1つです。行われている変更について詳しく学ぶには、github/名称変更を参照してください。

  • リリース候補からの既知の問題の修正

    • リリース候補1及びリリース候補2のすべての既知の問題は、以下の既知の問題のセクションにリストされているもの以外、すべて修正されました。

  • 他の問題の修正

    • 3.0.0への移行とアップグレードの問題が修正されました。

    • Backup Utilitiesのバージョン管理が、リリース候補のバージョンでも動作するようになりました。

    • Support Bundleを生成すると、orchestratorのログにエラーが残りました。

    • 大規模なリストアを行うと、Redisがメモリ不足になることがありました。

    • 管理コンソールのGitHub Actionsを有効化するチェックボックスは、どの認証方式でも表示されるようになりました。

    • GitHub Actionsは、必要なストレージも設定されている場合にのみ有効化できます。

    • MSSQLのレプリケーションが設定されていないと、ghe-repl-statusは何も出力せずに失敗することがあります。

    • 様々な種類のログに対するPIDの追加を含め、いくつかのログファイルのフォーマットが変更されました。これは、GitHub Enterprise Supportが問題のトラブルシューティングのためにサポートバンドルを利用する方法には影響しません。

    • webhookの 設定APIに対するPATCHリクエストは、webhookのシークレットを消去しなくなりました。

    • 特定の種類のpre-receiveフックが失敗しました。

    • Pachages NuGetサービスは、公開時にセマンティックバージョンを正規化するようになりました。無効なセマンティックバージョン(たとえばv1.0.0.0.0.0)はNuGetクライアントでダウンロードできず、NuGetサービスがそれらのバージョンを正規化することが期待されます(たとえばv1.0.0.0.0.0 --> v1.0.0)。オリジナルの正規化されていないバージョンは、verbatimVersionフィールドにあります。クライアントの設定を変更する必要はありません。

  • 新しくセットアップされたユーザを持たないGitHub Enterprise Serverで、攻撃者が最初の管理ユーザを作成できました。

  • カスタムのファイアウォールのルールは、アップグレードの際に維持されません。

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

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

  • メンテナンスモードが有効化されているとき、サービスの中に引き続き"active processes"としてリストされるものがあります。特定されたサービスは、メンテナンスモード中にも実行されることが期待されるものです。この問題が生じており、不確実な場合はGitHub Enterprise Support または GitHub Premium Supportにお問い合わせください。

  • GitHub Actionsが有効になっている場合、メンテナンスモードを解除するには 'ghe-maintenance -u'を使ってください。

  • /var/log/messages/var/log/syslog/var/log/user.logへの重複したロギングによって、ルートボリュームの使用率が増大します。

  • ユーザが、すべてのチェックボックスをチェックすることなく必須のメッセージを閉じることができます。

  • pre-receiveフックスクリプトは一時ファイルを書くことができず、そのためにスクリプトの実行が失敗することがあります。pre-receiveフックを使うユーザは、ステージング環境でスクリプトが書き込みアクセス権を必要とするかを確認するためのテストをするべきです。

  • リポジトリのデプロイキーが、LFSオブジェクトを含むリポジトリで使用できません。

  • ノートブックに非ASCIIのUTF-8文字が含まれている場合、Web UI中でのJupyter Notebookのレンダリングが失敗することがあります。

  • Web UIでのreStructuredText (RST) のレンダリングが失敗し、代わりにRSTのマークアップテキストがそのまま表示されることがあります。

  • 依存関係グラフがPythonのsetup.pyマニフェストファイルのパースに失敗し、HTTP 500エラーがログに残されます。これが重複されるロギングの問題と組み合わさると、ルートボリュームの使用率が増大します。

  • レース条件によって依存関係グラフデータベースの移行が失敗したように見えることがあります。

  • 以前のGitHub Enterprise Serverのリリースからアップグレードされた、カスタムのタイムゾーンを持つインスタンスは、Web UIに不正確なタイムスタンプがあることがあります。

  • Pagesの古いビルドがクリーンアップされず、ユーザディスク(/data/user/)を使い切ってしまうことがあります。

  • When deleting a branch after merging a pull request, an error message appears although the branch deletion succeeds.

  • GitHub Enterprise Server 2.19の非推奨化

    • GitHub Enterprise Server 2.19は、2020 年11月12日に非推奨となりました。これは、この日以降は重大なセキュリティの問題に対してであってもパッチリリースが行われなくなるということです。より優れたパフォーマンス、改善されたセキュリティ、新しい機能のために、GitHub Enterprise Serverの最新バージョンへのアップグレードをできるだけ早く行ってください。

  • 旧来のGitHub App webhookイベントの非推奨化

    • GitHub Enterprise Server 2.21.0から、2つの旧来のGitHub Appsに関連するwebhookイベントが非推奨となり、GitHub Enterprise Server 3.2.0で削除されます。非推奨となったイベントのintegration_installationintegration_installation_repositoriesには、サポートされることになる同等のイベントがあります。詳細な情報は非推奨化のアナウンスのblogポストにあります。

  • 旧来のGitHub Appsのエンドポイントの非推奨化

    • GitHub Enterprise Server 2.21.0から、インストールアクセストークンを作成するための旧来のGitHub Appsのエンドポイントが非推奨となり、GitHub Enterprise Server 3.2.0で削除されます。詳細な情報は非推奨化のアナウンスのblogポストにあります。

  • OAuth Application APIの非推奨化

    • GitHubは、パスパラメータとしてaccess_tokenを含むOAuthのアプリケーションエンドポイントをサポートしなくなりました。access_tokenをリクエストのボディに移すことにより、OAuth Appsのためのトークンをセキュアに管理できるようにする、新しいエンドポイントが導入されます。非推奨にはなりましたが、これらのエンドポイントはこのバージョンではまだ利用可能です。これらのエンドポイントは、GitHub Enterprise Server 3.4で削除しようとしています。詳細については非推奨化のアナウンスのblogポストを参照してください。

  • Semioticのサポートの非推奨化

    • サービスは、広く使われていなかったPull Requestのビューの"Find by Symbol"体験をサポートしました。

  • ワークフローコマンドの非推奨化

    • GitHub Actionsのset-env及びadd-pathワークフローコマンドは非推奨になりました。詳しい情報についてはchangelogを参照してください。

Did this doc help you?

Privacy policy

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

OR, learn how to contribute.