何が変わったのか

GitHubの10月19日発表によると、異常なトラフィックがある期間、github.comの可用性を守るため、公開リポジトリの一部の未認証HTTPS clone・fetchに認証を求める場合があります。影響する操作は認証が必要である旨のメッセージで失敗します。

対処は認証して再試行するか、一時保護の解除後に未認証で再試行することです。全プランが対象ですが、すべての公開リポジトリへの恒常的な認証義務ではありません。認証済みHTTPS、SSH、push、無関係なWeb・API通信はこの保護の対象外とされています。

以下は公式資料を踏まえた当サイトの切り分け手順です。認証を求めるエラーをすべてこの変更と決めつけず、対象を絞ってから対応します。

1. 何が失敗したのかを先に分ける

最初に次の項目を確認します。既存の設定や権限はまだ変更しません。

  • 接続先はgithub.comか。GitHub Enterprise Serverなど別ホストの問題ではないか。
  • 対象は公開リポジトリか。非公開リポジトリへのアクセス許可の問題ではないか。
  • 失敗したのはclone・fetchか。push、ブラウザのログイン、API呼び出しではないか。
  • 実際に使われた接続方式は未認証HTTPSか。認証済みHTTPSやSSHではないか。
  • エラーは認証を求めているか。それとも名前解決、証明書、接続先の誤りなど別の内容か。

例えば、架空のリポジトリAはブラウザで読めるのに、CIの取得処理だけ失敗したとします。この時点では、公開状態・CIの資格情報・一時保護のどれが原因かは未確定です。ブラウザでログインしていることは、別のCIやターミナルでGit認証できる証拠にはしません。公式の認証資料も、利用経路によって認証方法が異なると説明しています。

エラー文、発生日時、対象の公開範囲、失敗した工程を手元に残すと比較しやすくなります。ただし、生のCIログやURLをそのまま共有すると、秘密値や内部情報を含む場合があります。共有する記録は必要な部分だけにし、秘密値・個人情報を除きます。本記事には実際のエラーを再現した記録はありません。

2. PCではremoteと認証経路を確認する

既存のローカルリポジトリでは、GitHub公式手順のgit remote -vでremoteの名前・URL・fetch/pushの向きを確認できます。表示内容は手元だけで確認し、秘密値が埋め込まれたURLをチャットや問い合わせへ貼り付けないでください。新規cloneであれば、入力しようとしている取得先を確認します。

そのうえで次のように判断します。

  1. 認証を行えない・行う必要がない運用なら、保護解除後に再試行する方法を検討します。公式発表は解除までの固定時間を示していないため、「数分待てば必ず直る」とは扱いません。
  2. 認証が必要なら、正しいアカウントと対象を確かめ、組織で承認された認証経路を使います。ブラウザとGitの認証を区別します。
  3. 同じ取得操作を再試行し、取得先と必要な内容を確認します。取得の成功と、その後のビルド・テスト・公開の成功は別に確認します。

公式資料は、HTTPSのGit認証ではアカウントのパスワードによる認証を廃止済みとしています。Git Credential Managerなどの資格情報ヘルパーやGitHub CLIなど、利用環境に合う公式の経路を確認します。既存の資格情報を一括削除したり、手当たり次第にアカウントを切り替えたりする手順ではありません。

認証方式を新たに導入する場合は、管理者と権限・保存先・対象を先に決めます。認証要求が出たという理由だけで、リポジトリの書き込み権限を増やす必要があるとは限りません。

3. CIでは「どの取得処理が未認証か」を調べる

ワークフローには、最初のcheckoutだけでなく、追加リポジトリやスクリプト内のclone・fetchが含まれることがあります。当サイトの提案は、ジョブ全体に広い資格情報を配る前に、失敗している取得工程を特定することです。

GitHubの変更告知は、Actionsでは組み込みのGITHUB_TOKEN、他のCIではGitHub Appのinstallation access tokenを優先する方法を案内しています。具体的な導入は利用中のCI・組織方針・対象リポジトリに合わせて確認します。

actions/checkoutの公式READMEでは、tokenの既定値はワークフローのトークンで、通常の推奨権限はcontents: readです。一方、後続の独自スクリプトにも同じ認証が利用できるかは、使用版やpersist-credentialsなどの設定と照合します。checkoutがあるというだけで、すべての取得処理が認証済みとは決めません。

また、公式の認証資料ではGITHUB_TOKENの対象はワークフローを含むリポジトリに限定されます。別の非公開リポジトリの取得権限まで自動的に付くわけではありません。公開HTTPSの一時保護と、非公開リポジトリへのアクセス設計は別の問題です。

変更を行う場合も、テスト用の実行で取得・ジョブ・成果物を分けて確認します。秘密値をURLや実行ログへ出力しない方法を使い、取得失敗を成功扱いにして後続処理へ進めないようにします。

避けたい対処

次は当サイトの安全上の注意です。

  • 待ち時間なしに再試行を繰り返し、原因を調べずに負荷を増やす。
  • TLS証明書検証や多要素認証を無効にして認証エラーを解消しようとする。
  • トークンをremote URL、スクリプト、記事、スクリーンショットに書く。
  • 一時保護を理由に非公開リポジトリを公開したり、不要な書き込み権限を付ける。
  • SSHがこの保護の対象外であることを、接続方式を無条件で変更すべき理由にする。

特にSSHへの切り替えは、鍵・クライアント・社内接続方針の確認を伴う別の変更です。既存のSSH変更の解説も参照し、最新の公式案内を再確認してください。

完了の判断と残る未確認

対応記録には「対象・日時・失敗工程・選んだ対応・再試行結果・未確認事項」を残します。必要な取得に成功したら、用途に応じてビルド・テスト・成果物まで確認します。公開が目的なら、GitHubとCloudflareの接続確認のように、Git取得とは別に本番の内容を確かめます。

本記事は10月20日に公式本文を確認した解説で、一時保護の発生・解除、PC・CIの認証や再試行は実機検証していません。固定のエラー全文、HTTPコード、解除時刻は推測していません。基本用語は認証、認可、最小権限の原則で確認できます。